Openssh + AFS

[Douglas E. Engert]

Rainer Laatsch wrote:
> 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.
> 

Nice to hear. We have converted all newer systems to using the OpenAFS
aklog, but still have a few doing gssklog.

> 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.

You are addressing a real concern that the delegated credential by GSS
is a full TGT. In may situations, delegating just an AFS ticket
would be less risky. But it soulds like you are adderssing this by
doing the delegation at the SSH level. Have you looked at
what it would take to do this within GSS? Kerberos can forward more
then one ticket, but no one I know of has taken advantage of this.

> 
> 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.
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444