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.
Sorry, I'm too quick to click. That line is from /etc/pam.d/system-auth.
Could you attach your /etc/pam.d/system-auth?
And what returns getent passwd <theuser>?
Created attachment 112419 [details] /etc/pam.d/system-auth
That system-auth worked great under RHEL3. getent passwd brian returns: brian:x:4149:2500:Brian K Smith:/home/brian:/bin/bash
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
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...
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.
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. ;)
> 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.
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.
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 :)
This depends on pam_krb5 maintainer. Also you can enter the issue into the Issue Tracker.
This should have been fixed by 2.1.8-1. Please reopen this bug if you find that it wasn't.