[OpenAFS] Openafs Client with pam krb5 and ldap
Fri, 1 Oct 2010 13:18:46 -0400 (EDT)
On 2010-10-01 at 10:04, Russ Allbery ( email@example.com ) said:
> Andy Cobaugh <firstname.lastname@example.org> writes:
>> Two, I'm guessing this is debian?
> No, it's not Debian, although the common-* stuff made it look that way.
> But that's the Red Hat pam_krb5.
>> I've had issues making this work with GSSAPI on lenny, and have an
>> account section like this:
>> account sufficient pam_permit.so debug
>> account required pam_unix.so debug
>> I spent a great deal of time fighting this when we upgraded the couple
>> remaining debian machines here to lenny.
> windlord:~> cat /etc/pam.d/common-account
> # /etc/pam.d/common-account -- Authorization settings common to all services.
> account required pam_krb5.so
> account required pam_unix.so
> So I'd be very curious to hear more about what's breaking for you, since
> this should just work. (I'm the author of the pam-krb5 module used in
Sure, debian lenny.
libpam-krb5 = 3.11-4
libpam-afs-session = 1.7-1
If I have just this in common-account:
account required pam_unix.so debug
Then I try to login with gssapi ssh:
$ ssh foo
Connection closed by x.x.x.x
Only entry in auth.log:
Oct 1 13:09:23 apollo sshd: Authorized to phalenor, krb5 principal phalenor@BX.PSU.EDU (krb5_kuserok)
So we add in pam_krb5 in system-account like this, which appears to be
the default entry added when pam-krb5 is installed:
account [default=ignore ignore=ignore success=ok] pam_krb5.so debug
And same thing, connection closes. This is in auth.log:
Oct 1 13:10:59 apollo sshd: Authorized to phalenor, krb5 principal phalenor@BX.PSU.EDU (krb5_kuserok)
Oct 1 13:10:59 apollo sshd: (pam_krb5): none: pam_sm_acct_mgmt: entry (0x0)
Oct 1 13:10:59 apollo sshd: (pam_krb5): none: skipping non-Kerberos login
Oct 1 13:10:59 apollo sshd: (pam_krb5): none: pam_sm_acct_mgmt: exit (failure)
Only way to make it work is to add in pam_permit. I've done things like
run sshd with the highest debugging level, among other things, and nothing
I've done shows any indication that it's even failing. I think I deduced
that the account routine wasn't returning success, so I tried pam_permit,
it worked, and I stopped caring why.
I've seen this on every single lenny system I've installed (so, maybe 3?).
The defaults never worked for me. common-[auth|session|password] are all
stock otherwise, and /etc/pam.d/sshd directly includes all for common-*