The other approach is to not have any direct Kerberos or AFS support at all in ssh
or sshd. But rather use the GSSAPI and PAM with sshd to get AFS tokens
from the forwarded GSSAPI credentials i.e. forwarded K5 tickets. This then
avoids problems if the vendor did not compile in the options you wanted
or use the Kerberos distributions you wanted.

We use the vendor's pam_krb5 if possible for the keyboard interactive,
and a pam_afs2 for the kewyboard interactive, and gssapi session. pam_afs2
will get an AFS PAG and call your favoriate aklog to get a token.

Drop me a note if you would like more information.

Robert Banz wrote:

> Darren Tucker wrote:
>>Jan Bilang wrote:
>>>every time i enable the option "KerberosGetAFSToken yes" on a computer where
>>>the afs-client works fine i get a (/var/log/)message(s) like this:
>>>"sshd[1136]: rexec line 70: Unsupported option KerberosGetAFSToken".

>>In addtion to requiring Kerberos support, that option only works if your
>>Kerberos implementation has the required AFS bits (k_setpag() and a few
>>other calls) and at the moment, only Heimdal has them. There was talk
>>of adding them as an external library for MIT Kerberos but as far as I
>>know that's never happened.
>>Depending on what your OS vendors have done, it might be possible to
>>configure AFS to work via a PAM module, but that's going to be vendor
>>(Hmm, I see that FC3 has a "krbafs" package which implements some but
>>not all of the functions needed. I don't know if it could be made to

> I've actually gotten things to build with the krbafs package + MIT on
> multiple architectures (Solaris & OSX.) So, it's all there.
> -rob
> _______________________________________________
> openssh-unix-dev mailing list


Douglas E. Engert
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444

openssh-unix-dev mailing list