Can't get Russ' pam_krb5 module to work with ssh on RHEL5

Jason Edgecombe jason at rampaginggeek.com
Thu Mar 1 19:16:42 EST 2012


On 03/01/2012 06:43 PM, Russ Allbery wrote:
> "Edgecombe, Jason"<jwedgeco at uncc.edu>  writes:
>
>> I have Russ Allbery's pam_krb5 and pam_afs_session modules working for
>> console logins, but they fail for ssh logins (both password and
>> kerberized).  I can get ssh logins to work with RedHat's pam_krb5
>> module, but RedHat's module causes problems with AFS tokens and Gnome
>> (gconfd).  Disabling ssh privilege separation doesn't make a
>> difference. Any help is appreciated.
>> Platform: RHEL 5.6 x86_64
>> Here is the log from the password login:
>> Mar  1 16:39:08 myhost sshd[22409]: pam_krb5(sshd:account): pam_sm_acct_mgmt: entry
>> Mar  1 16:39:08 myhost sshd[22409]: pam_krb5(sshd:account): skipping non-Kerberos login
>> Mar  1 16:39:08 myhost sshd[22409]: pam_krb5(sshd:account): pam_sm_acct_mgmt: exit (ignore)
>> Mar  1 16:39:08 myhost sshd[22409]: fatal: Access denied for user jwedgeco by PAM account configuration
> The first thing that jumps out here is that apparently the auth
> functionality of pam-krb5 never ran.  Either that, or debug wasn't enabled
> for auth, but the account group is also saying that the user didn't log on
> with Kerberos.
>
>> Contents of /etc/pam.d/system-auth-ac:
>> #%PAM-1.0
>> # This file is auto-generated.
>> # User changes will be destroyed the next time authconfig is run.
>> auth        optional      pam_group.so
>> auth        required      pam_env.so
>> auth        sufficient    pam_unix.so nullok try_first_pass
>> auth        requisite     pam_succeed_if.so uid>= 104 quiet
>> auth        sufficient    /usr/local/lib/security/pam_krb5.so use_first_pass
>> auth        required      pam_deny.so
> Does the user's UNIX password match their Kerberos password?  If so, then
> pam_unix will succeed and nothing subsequent to that will run, so no
> Kerberos authentication was ever performed.
No, the local users are locked in the shadow file. The users have a "*" 
in the password field for the /etc/shadow file. I'm using nssdb for 
passwd and shadow file if that matters.
>> Here is the log from the kerberized login:
> This is a different problem.
>
>> Mar  1 16:39:15 myhost sshd[22412]: Authorized to jwedgeco, krb5 principal jwedgeco at MYREALM (krb5_kuserok)
>> Mar  1 16:39:15 myhost sshd[22412]: pam_krb5(sshd:account): pam_sm_acct_mgmt: entry
>> Mar  1 16:39:15 myhost sshd[22412]: pam_krb5(sshd:account): skipping non-Kerberos login
>> Mar  1 16:39:15 myhost sshd[22412]: pam_krb5(sshd:account): pam_sm_acct_mgmt: exit (ignore)
> This part is expected, I think.  The account group for pam-krb5 only makes
> sense in combination with a password authentication.  If you authenticate
> via GSS-API, sshd is responsible for doing the authorization check and
> there isn't anything for PAM to do.
>
>> Mar  1 16:39:15 myhost sshd[22412]: fatal: Access denied for user jwedgeco by PAM account configuration
>> account     required      pam_unix.so broken_shadow
>> account     sufficient    pam_succeed_if.so uid<  104 quiet
>> account     [default=bad success=ok user_unknown=ignore] /usr/local/lib/security/pam_krb5.so
>> account     required      pam_permit.so
> default=bad is mapping ignore to fail.  You need to add ignore=ignore to
> your configuration for the pam_krb5 line.  (You don't need
> user_unknown=ignore for my PAM module; it won't return user_unknown unless
> validation of a Kerberos login actually fails.)
>



More information about the Kerberos mailing list