Now with PAM? Solaris 10 sshd and ticket forwarding

Jeff Blaine jblaine at kickflop.net
Mon Nov 5 14:43:56 EST 2007


Those 3 lines make it work.  Thanks again, Doug.

I can't really imagine where I'd be with this unless
someone had figured out all of this esoterica before
me.  Sheesh.

Douglas E. Engert wrote:
> The problem may be in the pam.conf. With sshd-gssapi,
> only the PAM session and account routines are called, and
> you don't use the pam_krb5. The sshd stores the credentials
> for you,not PAM.
> 
> We use this in /etc/pam.conf, (but all uncommented.)
> Try with just the 3 uncommented lines.
> 
> 
> sshd-gssapi   account requisite  pam_roles.so.1
> sshd-gssapi   account required   pam_unix_account.so.1
> #sshd-gssapi   account required   /krb5/lib/pam_krb5_ccache.so.1  
> ccache=/tmp/krb5cc_%u_%p
> 
> sshd-gssapi   session required  pam_unix_session.so.1
> #sshd-gssapi   session required  /krb5/lib/pam_afs2.so.1
> #sshd-gssapi   session required  /krb5/lib/pam_krb5_ccache.so.1  clean
> 
> The pam_afs2 is the local equivelent of pam_afs_session which should
> also work.
> 
> The pam_krb5_ccache sets the KRB5CCNAME to force a clean cache, to avoid
> some bugs which Sun may have fixed, then cleans up the cache when the
> session ends.
> 
> 
> 
> Jeff Blaine wrote:
>> [ Thanks to all of you for the previous help, BTW! ]
>>
>> Let's try this with PAM now.  Ignore the previous work
>> which ended up working (see messages last week).
>>
>> What works: I can ssh into the server and get krb5 creds
>> (all PAM with sshd-gssapi entries).
>>
>> What doesn't work:  I had to enter a password, so ticket
>> forwarding is not working as expected.
>>
>> I'm obviously trying to get a working solution here that
>> does not require any 3rd party workings to at least get
>> this far (yes, the 3rd party pam_afs_session will be used
>> at a later point to get AFS tokens from krb5 creds).
>>
>> Client-side tickets were forwardable and the client-side
>> ssh command was:
>>
>>      /usr/bin/ssh -o "GSSAPIDelegateCredentials yes" -o
>>      "GSSAPIAuthentication yes" alberta
>>
>> == Log data ======================================================
>> ...
>> debug1: Client offered gssapi userauth with { 1 2 840 113554 1 2 2 }
>> (supported)
>> debug1: Received delegated GSS credentials
>> PAM-KRB5 (acct): debug=1, nowarn=0
>> PAM-KRB5 (acct): no module data for KRB5_AUTOMIGRATE_DATA
>> PAM-KRB5 (acct): no module data
>> PAM-KRB5 (acct): end: Ignore module
>> PAM-KRB5 (setcred): start: nowarn = 0, flags = 0x1
>> PAM-KRB5 (setcred): kmd get failed, kmd=0x0
>> PAM-KRB5 (setcred): end: Can not retrieve user credentials
>> Failed gssapi-with-mic for jblaine from xxx.xx.11.213 port 36762 ssh2
>> ...
>> # A few other failed gssapi-with-mic attempts here (labeled
>> # as unsupported)
>> ...
>> debug1: Storing delegated GSS-API credentials
>> debug1: temporarily_use_uid: 26560/10 (e=0/0)
>>
>> == sshd_config ===================================================
>> ...
>> GSSAPIAuthentication yes
>> GSSAPIKeyExchange yes
>> GSSAPIStoreDelegatedCredentials yes
>> ...
>>
>> == pam.conf ======================================================
>> sshd-gssapi   auth requisite      pam_authtok_get.so.1
>> sshd-gssapi   auth required       pam_dhkeys.so.1
>> sshd-gssapi   auth sufficient     pam_krb5.so.1 debug
>> sshd-gssapi   auth required       pam_unix_auth.so.1
>> sshd-gssapi   account requisite   pam_roles.so.1
>> sshd-gssapi   account required    pam_unix_account.so.1
>> sshd-gssapi   account required    pam_krb5.so.1 debug
>> sshd-gssapi   session required    pam_unix_session.so.1
>> sshd-gssapi   session required    pam_krb5.so.1 debug
>>
>> ________________________________________________
>> Kerberos mailing list           Kerberos at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>
>>
> 



More information about the Kerberos mailing list