Openssh + AFS

Rainer Laatsch Laatsch at uni-koeln.de
Thu May 29 13:45:05 EST 2008


Hello Mr. Engert,
I am very glad to hear from you. I learned a lot inspectng the code of
yourn'gssklog*' (and also 'GetToken/SetToken' of Mr. Toebbicke @ CERN).
Though we have not switched (yet) to final usage of krb5, our testbed uses
your 'gssklog*' effectivly.

My latest message shows how to get credentials. It is easy to get an
AFS token at once (instead of getting an Krb5 ticket and then struggling
to get the AFS token).

If the tickets reside solely in AFS space, that's good. The standard
krb5 setup leaves ticket files (effectively equivalent to the password)
on every server. This concept might have been enforced by
 NationakSecurityAgencies
which I dont want to assist; except under official legal issues.

I will contribute a PAM nodule (soon); all the base works can be found
already in
 /afs/rrz.uni-koeln.de/admin/public/openssh-4.7p1-PatchDir/


Best regards,
Rainer Laatsch

On Wed, 28 May 2008, Douglas E. Engert wrote:
> > The use of Krb5 ticket passing with GSS-API is thought to be useful.
>
> Yes it is useful. When used with something like pam_afs_session,
> it can get a AFS token.
>
> > But the authentication is done 'under the hood'; the administrator
> > has no chance to issue finer controls regarding the ticket contents.
>
> The k5start method as suggested by mloftis at wgops.com sounds interesting,
> as the user then sets the AFS ACLs to let selected hosts read access
> to the ~/.ssh directory...
>
> Not clear if there is a risk here. Any delegated tickets are encrypted
> in a key contained in the the Kerberos service ticket. So in effect you have
> authenticated with Kerberos but you still want to authenticate with the
> SSH keys. If this SSH key authentication fails, you have given away the
> delegated tickets.



More information about the openssh-unix-dev mailing list