Kerberos tickets, SSH public key auth, AFS tokens

[Jeff Blaine]

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