Bug 151164 - SSH doesn't allow public/private key authentication with pam kerberos
SSH doesn't allow public/private key authentication with pam kerberos
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: pam_krb5 (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-15 10:42 EST by Brian Smith
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version: 2.1.8-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-11 11:16:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/etc/pam.d/system-auth (1.09 KB, text/plain)
2005-03-29 10:59 EST, Brian Smith
no flags Details

  None (edit)
Description Brian Smith 2005-03-15 10:42:41 EST
Description of problem:

When using pam and kerberos to ssh to another machine password login
works fine, unless the user has a public private key combo.  Then no
login at all is possible.

If the user is given a shadow password things work again, or if line:
    account     sufficient    /lib/security/$ISA/pam_succeed_if.so uid
< 100 quiet
is changed to:
    account     sufficient    /lib/security/$ISA/pam_succeed_if.so uid
< 5000 quiet
things then work again.  Perviously, on RHEL3 this was not necessary.
Comment 1 Brian Smith 2005-03-15 10:43:42 EST
Sorry, I'm too quick to click.  That line is from /etc/pam.d/system-auth.
Comment 2 Tomas Mraz 2005-03-29 10:29:58 EST
Could you attach your /etc/pam.d/system-auth?
Comment 3 Tomas Mraz 2005-03-29 10:38:15 EST
And what returns getent passwd <theuser>?
Comment 4 Brian Smith 2005-03-29 10:59:41 EST
Created attachment 112419 [details]
/etc/pam.d/system-auth
Comment 5 Brian Smith 2005-03-29 11:00:54 EST
That system-auth worked great under RHEL3.

getent passwd brian returns:
brian:x:4149:2500:Brian K Smith:/home/brian:/bin/bash
Comment 6 Tomas Mraz 2005-03-29 11:09:03 EST
The problem is I cannot reproduce the problem here, are you sure that it still
happens for you (because for example a missing broken_shadow option of the
account pam_unix could affect this). This option was added to system-auth due to
a bug fix in pam which changed the default behavior. Also if it still happens
for you, does it help if you change the passwd line so there is
brian:*K*:4149:2500:Brian K Smith:/home/brian:/bin/bash
Comment 7 Brian Smith 2005-03-29 11:22:16 EST
Hmm....yes, if I lower the 5000 to 100 it still fails, and *K* doesn't help.

This also appears to be a problem in Fedora: Bug 113247.  This has some more
suppostions...
Comment 8 Tomas Mraz 2005-03-29 11:46:12 EST
Hmmm if the bug is in pam_krb5 - as it's suggested in the bug 113247, then how
it could help adding a password to /etc/shadow for the user? The pam_krb5 would
be called anyway and so it shouldn't pass through it just the same as in the
original case.
Comment 9 Brian Smith 2005-03-29 13:20:59 EST
The way system-auth is set, up since unix is first and both are 'sufficient', I
think it will fail over if the shadow entries aren't there, or locked.

Most of my users have PC accounts and then use the single sign on via Windows
kerberos, but some accounts only get unix and use the shadow.

The failure only happens when a user has an id_[dr]sa[.pub] in their .ssh
directory, which should allow them to ssh w/o a password prompt.

Are there negative ramifications to keeping that < uid at a higher number?

Thanks, I know it's hard when you can't dup the problem.  You'd be welcome
to a login. ;)
Comment 10 Tomas Mraz 2005-03-29 13:38:56 EST
> Are there negative ramifications to keeping that < uid at a higher number?

This effectively means that you disable authorization by the krb5 server so it's
not possible to for example expire or lock the account on the central server.

Could you try to rebuild and install openssh-4.0p1 from Fedora Core development
and test if it helps?

Or you could experiment with adding debug option to the auth and account
pam_krb5 lines and attaching the relevant syslog output here - for the case with
and without the shadow entry.

About duplicating the problem - maybe I can't duplicate it as I authenticate
against an Linux machine with kerberos server, not a Windows one.
Comment 11 Tomas Mraz 2005-03-29 14:18:13 EST
Hmm... actually instead of rebuilding and installing the openssh-4.0p1 from
Fedora Core development, could you try rebuilding and installing the
pam_krb5-2.1.5-1.src.rpm from Fedora Core development? It seems to have the fix
from bug 113247 included.
Comment 12 Brian Smith 2005-03-29 16:10:27 EST
Bingo!  FC development's pam_krb5-2.1.5-1.src.rpm fixes the problem.

So will this come out in up2date soon, or should I manually patch?  I don't mind
waiting a couple months, but not until RHEL5 :)

 
Comment 13 Tomas Mraz 2005-03-29 16:27:52 EST
This depends on pam_krb5 maintainer. Also you can enter the issue into the Issue
Tracker.
Comment 14 Nalin Dahyabhai 2006-08-11 11:16:57 EDT
This should have been fixed by 2.1.8-1.  Please reopen this bug if you find that
it wasn't.

Note You need to log in before you can comment on or make changes to this bug.