PAM and GSSAPI SSH authentication conflict

Rachel Elizabeth Dillon red at MIT.EDU
Fri Oct 8 15:16:36 EDT 2004

Thank you! I had to tweak some things to the modules that I had, and take
out some modules I didn't have, but I was able to get the right behavior

#ssh            auth        required
ssh             auth        sufficient 
ssh             auth        sufficient try_first_pass 
#ssh            auth        required

ssh             account     required
ssh             account     sufficient 

ssh             password    sufficient try_first_pass 
#ssh            password    required

#ssh            session     required
ssh             session     required
ssh             session     optional

I don't _think_ there is any problem with having those other lines
commented out, but I am not a PAM wizard. Thank you again for the help!


On Fri, Oct 08, 2004 at 01:58:07PM -0500, Kasundra, Digant wrote:
> This is what our pam file looks like:
> auth        required      /lib/security/$ISA/
> auth        sufficient    /lib/security/$ISA/ likeauth nullok
> auth        sufficient    /lib/security/$ISA/ use_first_pass
> auth        required      /lib/security/$ISA/
> account     required      /lib/security/$ISA/
> account     [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore] /lib/security/$ISA/
> password    required      /lib/security/$ISA/ retry=3 type=
> password    sufficient    /lib/security/$ISA/ nullok use_authtok md5 shadow
> password    sufficient    /lib/security/$ISA/ use_authtok
> password    required      /lib/security/$ISA/
> session     sufficient    /lib/security/$ISA/ skel=/etc/skel/ umask=0077
> session     required      /lib/security/$ISA/
> session     required      /lib/security/$ISA/
> session     optional      /lib/security/$ISA/
> The biggest difference that I see is the account and session lines.  We require 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 on behalf of Rachel Elizabeth Dillon
> Sent: Fri 10/8/2004 1:12 PM
> To: kerberos at
> 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 try_first_pass 
> ssh             account required 
> ssh             session required 
> ssh             password required 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :

More information about the Kerberos mailing list