SSH Key Authentication and AFS Token Passing

The first part of this document describes a way to set up your ~/.ssh/ directory so that you only need a token on the client side for key-based authentication. This configuration will enable a remote sshd to read your public keys without a token, while keeping your private keys safe. The second part describes patching OpenSSH to restore the older-style AFS token-passing functionality, where key-based authentication worked out-of-the-box.

Background

SSH Key Authentication no longer works in recent versions of OpenSSH if your home directory lives in AFS. In older (pre-2.9) versions of OpenSSH, your token would be passed across during the authentication phase, so the remote sshd could read your ~/.ssh/authorized_keys file. (It needed this since the whole directory is hopefully ACL'd to keep people out, as your private keys live there, too.) Since the remote sshd could then read files in your ~/.ssh dir, key authentication could happen normally, and all was good.

Currently, however, OpenSSH does not accept passed AFS tokens until after authentication has already taken place. Since the remote sshd doesn't have a token to read your authorized_key file, it falls back to other authentication methods. Once you're authed and it hits the session phase, then and only then does the AFS token get passed. The general consensus is that this was changed because passing an AFS token before actual authentication happened was seen as a security risk.

Method 1: Directory Voodoo

Remember, the remote sshd only needs to be able to read your authorized_keys file in your ~/.ssh dir, and needs to be able to do so without having an AFS token. Since this file only contains public keys, it doesn't matter who can read them.

Create a subdirectory of your ~/.ssh dir (we'll call it " private/ ") and ACL it so only you can do anything within it. Move your private keys into that directory. Symlink to them from the ~/.ssh directory and give system:anyuser read/lookup access to your ~/.ssh dir.

You now have a ~/.ssh dir with " system:anyuser rl " access that contains only public keys and symlinks to your private keys, and a subdirectory to which only you have rights that contains the actual private keys.

So here's what happens now: (Assuming SSH1/RSA auth)

You attempt an SSH1 connection to host2 from host1, using RSA key authentication. The sshd on host2 needs to look in your authorized_keys file, and can now do so without the AFS token. Your ssh client process on host1 already has access to your AFS token, so it can read ~/.ssh/private/identity (your SSH1 private RSA key). Authentication proceeds as normal. After you're authed, then your AFS token gets passed across, and life proceeds as normal.

The directory layout (and permissions for the PTS group system:anyuser) looks something like this:

 ${HOME}   ( system:anyuser l )
     |
     +--- .ssh/   ( system:anyuser rl )
            |
            +--- private/   ( system:anyuser none )
            |         |
            |         +--- identity
            |         +--- id_rsa
            |         +--- id_dsa
            |
            +--- authorized_keys
            +--- authorized_keys2
            +--- indentiy.pub
            +--- id_rsa.pub
            +--- id_dsa.pub
            +--- identity --symlink--> ./private/identity
            +--- id_rsa   --symlink--> ./private/id_rsa
            +--- id_dsa   --symlink--> ./private/id_dsa
            +--- known_hosts, known_hosts2, etc...

The remote sshd only needs to read your public keys stored in the authorized_keys file, which it can read without a token. As long as you have a token on the ssh-client side, you can read your private keys (symlinked into the place ssh expects to find them) for the client half of the key-based auth.

The remote sshd doesn’t like it if your home or ~/.ssh directories have group write permissions. Your home directory should be writable only by you, ~/.ssh should be 700, and authorized_keys should be 600 :

 > chmod g-w /home/your_user
 > chmod 700 /home/your_user/.ssh
 > chmod 600 /home/your_user/.ssh/authorized_keys

The glaring drawback to this cheap hack is that your users have to set this up for themselves. However, writing a simple shell script wrapper for ssh that checks for the existance of this subdirectory and performs the above voodoo if it doesn't would not be too terribly difficult.

Method 2: Patching OpenSSH

An alternative is to patch OpenSSH to pass AFS tokens before attempting key authentication. This will allow the remote sshd to once again be able to read the contents of your ~/.ssh/ directory, and more specifically, the authorized_keys file that resides within.

Patches can be found at: http://www.pitt.edu/~rlink/patches/

For the sake of compatibility with both older and newer versions of OpenSSH, these patches attempt AFS token and Kerberos TGT passing both before and after the authentication phase.

There's not really much else to say here, because all these patches do is revert OpenSSH to its previous well-documented behaviour.

-- ?RayLink - 26 Feb 2003