PAM and GSSAPI SSH authentication conflict

[Rachel Elizabeth Dillon]

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
with:

#ssh            auth        required      pam_env.so
ssh             auth        sufficient    pam_unix_auth.so.1 
ssh             auth        sufficient    pam_krb5.so.1 try_first_pass 
#ssh            auth        required      pam_deny.so

ssh             account     required      pam_unix_account.so.1
ssh             account     sufficient    pam_krb5.so.1 

ssh             password    sufficient    pam_krb5.so.1 try_first_pass 
#ssh            password    required      pam_deny.so

#ssh            session     required      pam_limits.so
ssh             session     required      pam_unix_session.so.1
ssh             session     optional      pam_krb5.so.1

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!

-r.


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/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.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20041008/49b4a31f/attachment.bin