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@mit.edu >> https://mailman.mit.edu/mailman/listinfo/kerberos >> >> > ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos