PAM and GSSAPI SSH authentication conflict

[Kasundra, Digant]

This is what our pam file looks like:

auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
auth        sufficient    /lib/security/$ISA/pam_krb5.so use_first_pass
auth        required      /lib/security/$ISA/pam_deny.so
                                                                                                                                       
account     required      /lib/security/$ISA/pam_unix.so
account     [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore] /lib/security/$ISA/pam_krb5.so
                                                                                                                                       
password    required      /lib/security/$ISA/pam_cracklib.so retry=3 type=
password    sufficient    /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
password    sufficient    /lib/security/$ISA/pam_krb5.so use_authtok
password    required      /lib/security/$ISA/pam_deny.so
                                                                                                                                       
session     sufficient    /lib/security/$ISA/pam_mkhomedir.so skel=/etc/skel/ umask=0077
session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so
session     optional      /lib/security/$ISA/pam_krb5.so

The biggest difference that I see is the account and session lines.  We require pam_unix.so first.  This is because the account information (ie who are you, what is your uidnumber, what is your home directory, etc) is not stored in kerberos, but locally.  (Actually, its stored in LDAP but the local nsswitch knows to look in there, pam doesn't know about all of that here).



-----Original Message-----
From: kerberos-bounces at mit.edu on behalf of Rachel Elizabeth Dillon
Sent: Fri 10/8/2004 1:12 PM
To: kerberos at mit.edu
Subject: PAM and GSSAPI SSH authentication conflict
 
I am building a network that uses Kerberos for authentication. The original
plan was to have a single bastion host to which users sshed, and logged in
using their Kerberos password. From that bastion host, users could then 
ssh to any other machine on the network, authenticatning via forwardable
Kerberos tickets and GSSAPI. I had this working. But, as always happens
with these things, requirements changed.

I am currently evaluating the feasibility of having every machine on the
network accept either Kerberos tickets or a Kerberos password as an
authentication mechanism. I believe that this _should_ work, but I haven't
been able to make it work. I have the following lines in /etc/pam.conf :

ssh             auth    required        pam_krb5.so.1 try_first_pass 
ssh             account required        pam_krb5.so.1 
ssh             session required        pam_krb5.so.1 
ssh             password required       pam_krb5.so.1 try_first_pass

If I comment these lines out, I get authentication just fine without
tickets but, unsurprisingly, no password-based authentication via PAM.
With the lines in place, if I ssh in with appropriate Kerberos tickets,
I get a host ticket but the following error in sshd -d -d -d :

debug1: userauth-request for user ptadmin service ssh-connection method external-keyx
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method external-keyx
Authorized to ptadmin, krb5 principal ptadmin at IC.COM (krb5_kuserok)
debug2: pam_acct_mgmt() = 17
PAM rejected by account configuration[17]: User account has expired

To the best of my knowledge the account is not expired, since it can log 
in just fine either with its Kerberos password or with those lines commented
out. I tried googling on this phrase and found a variety of errors related
to password expiry (reasonable), but this user account does not even _have_ 
a local password; no accounts do in our system. I would expect Solaris to
do the right thing and not count them as expired passwords in this case, but
maybe PAM gets tripped up? I'm not sure.

Anyway, any help would be appreciated. I'm using stock Debian OpenSSH 3.6,
except recompiled for Solaris.

Thanks!

-r.