openssh unix dev - May 2008 - Openssh + AFS

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.
But the authentication is done 'under the hood'; the administrator
has no chance to issue finer controls regarding then ticket contents.
When the ticket is accepted but not sufficient to open up the home dir,
the user must be forced out in the behind.

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

--On May 27, 2008 7:34:42 PM +0200 Rainer Laatsch <Laatsch at
Uni-Koeln.de>
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.
> But the authentication is done 'under the hood'; the administrator
> has no chance to issue finer controls regarding then ticket contents.
> When the ticket is accepted but not sufficient to open up the home dir,
> the user must be forced out in the behind.
>
> 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. 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.
I run sshd under k5start so it can obtain tokens to read public-key files 
from users.  The ACLs are set by default to allow the daemon RO access. 
Users still need to use GSS-API though or they get 'forced out in the 
behind' as you call it when they can't access their homedir.
>
> 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


--
"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler

On 2008-05-27 17:34, 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.
The authorized_keys file doesn't have to reside in the user's home 
directory. In many cases it is preferable if it is not. See the 
AuthorizedKeysFile directive. I often use something like:

AuthorizedKeysFile /etc/ssh/keys/%u

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>
"Never try to retrieve anything from a bear."--National Park Service

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

You are possibly right. But not coding too soon gives you time to think
about what finally should be the outcome.

Mit freundlichem Gruss
Rainer Laatsch
________________________________	______________________
E-mail: Laatsch at Uni-Koeln.DE		Universitaet zu Koeln
					Reg. Rechenzentrum (ZAIK/RRZK)
Fax   : (0221) 478-5590			Robert-Koch-Str. 10
Tel   : (0221) 478-5582			D-50931 Koeln

On Wed, 28 May 2008, Gert Doering wrote:
> Hi,
>
> On Wed, May 28, 2008 at 10:51:00AM +0200, Rainer Laatsch wrote:
> > The user cannot create that by himself. Should the admin manually
fulfill
> > requests if there are > 50000 users? (Current count: 50090)
>
> An admin worth his money should be able to script something that creates
> proper files/subdirectories automatically.
>
> gert
>

SSH key login and finally getting an AFS token can be made working like 
this. It uses the feature of the shell to include a .bashrc or .kshrc
upon every reexec of the shell.

- move all .profiles to a public subdir ( $HOME/public ) ;
   AFS acl's "system:anyuser rl"
- make links from $HOME/ to these ->  $HOME/public/
- move authorized_keys from .ssh/ to  $HOME/public/authorized_keys 
- make link .ssh/authorized_keys  to  $HOME/public/authorized_keys
- for $HOME and $HOME/.ssh, the acl's "?LOGNAME all system:anyuser
none"
   may be left like that (no change whatever).
Thats all for the setup.

Have a key made:
- ssh-keygen  -N '' ...  (say into .ssh/id_rsa)
- cat .ssh/id_rsa.pub >> $HOME/public/authorized_keys

This is the point: Add in front of your .bashrc / .kshrc
# ---
[ "$PAGSHDONE" ==""] &&
       export PAGSHDONE=true &&
         exec /usr/afsws/bin/pagsh -c "exec $SHELL"
[ "$TOKENDONE" == "" ] &&
       export TOKENDONE=true &&
         /opt/krb5/bin/gssklog    # or aklog, whatever

Now always ssh to $host in 2 steps:

  scp /tmp/krb5cc_$uid $host  &&
       ssh $host

To remedy the case of leftover tickets, the end of your .bashrc / .kshrc 
may read
# ---
tty -s || kdestroy  #throw away when interactive; does not influence scp


Best regards,
Rainer Laatsch

> Now always ssh to $host in 2 steps:
>   scp /tmp/krb5cc_$uid $host  &&
>      ssh $host
Should be:
    scp -p /tmp/krb5cc_$uid $host:/tmp/krb5cc_$uid  &&
       ssh $host
> To remedy the case of leftover tickets, the end of your .bashrc / .kshrc
> may read
> # ---
> tty -s || kdestroy  #throw away when interactive; does not influence scp
Should be:
  tty -s && kdestroy  #throw away when interactive; does not influence
scp

Best regards,
Rainer Laatsch