On 12/16/2009 5:39 PM, Douglas E. Engert wrote: > Jeff Blaine wrote: >> Long ago, we evaluated the facilities within OS-provided >> sshd for handling our Kerberos + OpenAFS authentication >> needs. That is, things like the Kerberos* settings, >> GetAFSToken or whatever it was called, etc. >> >> We found it to be an unusable mismatched moving target. >> >> We decided to do everything via PAM, with the exception >> of ssh public key auth for those who choose to use it >> and not get OpenAFS tokens automatically. >> >> It works great thanks to pam_krb5 and pam_afs_session >> from Russ Alberry. >> >> Our problem now is, of course, that people are complaining >> about the number of times they have to type a password. >> >> Can some of you hint to me what I should be researching >> as a solution to this? Essentially we need a non-interactive >> way to get OpenAFS tokens via krb5 creds, and I am pretty >> clueless about such things. More specifically, this has >> all come about from users complaining about CVS-via-SSH >> requiring a password in order to get tokens. > > ssh could use "GSSAPIDelegateCredentials yes" to forward > Krb5 tickets, and the sshd could then use pam_afs_session > to get the token, even for CVS. > > But this won't work with ssh public keys. If its winCVS > on Windows you are interested in, it too can support GSSAPI.
Thanks for the reply Doug Well, public keys aren't a requirement. I probably didn't make that clear, as it's a long story, so I apologize. Ignoring public keys, and after configuring a 'host' service principal, then extracting it, this does in fact work between two Solaris 10 boxes. Cool. Now I just need to figure out the pam_afs_session part. With some sshd-gssapi service lines in /etc/pam.conf, I'm stuck here (pam_krb5 is Russ'): # these first 4 lines seem unnecessary for sshd-gssapi here, no? sshd-gssapi auth requisite pam_authtok_get.so.1 sshd-gssapi auth sufficient pam_krb5RA.so try_first_pass forwardable minimum_uid=92 debug sshd-gssapi auth required pam_unix_auth.so.1 sshd-gssapi auth required pam_unix_cred.so.1 sshd-gssapi auth optional pam_afs_session.so minimum_uid=92 debug sshd-gssapi session optional pam_krb5RA.so minimum_uid=92 debug sshd-gssapi session optional pam_afs_session.so minimum_uid=92 debug sshd[20489]: [ID 800047 auth.info] Accepted gssapi-keyex for jblaine from 1xx.xx.10.14 port 60103 ssh2 sshd[20489]: [ID 366013 auth.debug] pam_krb5(sshd-gssapi): pam_sm_open_session: entry (0x0) sshd[20489]: [ID 366013 auth.debug] pam_krb5(sshd-gssapi): no context found, creating one sshd[20489]: [ID 366013 auth.debug] pam_krb5(sshd-gssapi): pam_sm_open_session: entry (0x0) sshd[20489]: [ID 366013 auth.debug] pam_krb5(sshd-gssapi): no context found, creating one sshd[20489]: [ID 366013 auth.debug] pam_krb5(sshd-gssapi): (user jblaine) unable to get PAM_KRB5CCNAME, assuming non-Kerberos login sshd[20489]: [ID 366013 auth.debug] pam_krb5(sshd-gssapi): pam_sm_open_session: exit (ignore) sshd[20489]: [ID 366013 auth.debug] pam_krb5(sshd-gssapi): (user jblaine) unable to get PAM_KRB5CCNAME, assuming non-Kerberos login sshd[20489]: [ID 366013 auth.debug] pam_krb5(sshd-gssapi): pam_sm_open_session: exit (ignore) sshd[20489]: [ID 237248 auth.debug] (pam_afs_session): pam_sm_open_session: entry (0x0) sshd[20489]: [ID 237248 auth.debug] (pam_afs_session): skipping tokens, no Kerberos ticket cache ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
