Openssh + AFS

[Douglas E. Engert]

Rainer Laatsch wrote:
> The native authentication methods of openssh are
> (not counting insecure RhostsRSAAuthentication)
> 1) public key
> 2) password
> For users with home dirs in AFS space, method 1) does not work.
> Except with (non foolproof) fiddling on the access controls within
> the home directory. This might lead to security issues when done
> by inexperienced users.
> 
> Without some work, only 2) remains. Being forced to send the most
> intimate credential instead of an ssh-key is not that nice.
> 
> 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 then ticket contents.

That is a GSSAPI restriction. Delegation is a single flag. The Kerberos
protocol allows for multiple tickets to be delegated, but with GSS
currently a full ticket granting ticket is sent.  You might want to
bring up the issue with the IETF Kitten (GSSAPI) working group.
There is also the Kerberos OK_TO_DELEGATE flag as an advisory to the
client. But this too is not fine grained.


> When the ticket is accepted but not sufficient to open up the home dir,
> the user must be forced out in the behind.

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

Or if the user sets up ACLs for the home directory, ~/.ssh directory
and adds symlinks in the ~/.ssh directory for files that must be
readable only by the user to some ~/.private directory the the sshd
can read some data without a AFS token. until and AFS token is
obtained after the authentication by pam_afs_session.

> 
> I would like to propose an initial credential exchange phase. The client
> might send ticket, x509-creds, afs-tokens or whatever. This should not
> authenticate the user, but help in authentcation with other methods.
> If activation of these credentials allows access to the AFS home dir,
> standard ssh-key authentication can be done.

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.

> So a double
> authentication is enforced: the credentials must be sufficient for AFS
> and an ssh-key (from within protected AFS space) authentication has to be
> successful.
> 
> Patches for a working example can be found in
>  /afs/rrz.uni-koeln.de/admin/public/openssh-5.0p1-PatchDir/
> It implements AFS-Token-passing and Krb5-ticket-passing for protocol-2
> (adding X509-cred-passing should be easy).
> A flag 'AllowCredPassing' in the ssh config files might increase the
> acceptability for that.
> 
> Best regards,
> Rainer Laatsch
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
> 

-- 

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