Afs token passing over ssh

Ssh prior to version 2 was able to forward all your afs tokens to the server side. It can't do that any more but there is a somewhat complicated workaround.

Here's what you want to do:

make ~/.ssh world readable and move private ssh config files to a private subdir
move your .Xauthority out of afs, for security and locking reasons
use kerberos authentication with ticket passing
turn off strict mode checking (afs doesn't use modes)
transform the ticket to an afs token on the server side

There are several problems with this approach:

you can only forward a single credential (a big problem for me)
you can't delegate creds unless you use kerberos auth
some versions of ssh won't fall back to rsa and password if gss fails
it's fragile and hard to set up compared to the token-forwarding of v1
you need help from your kerberos administrator to set it up

Client Side Setup

cd ~/.ssh
fs sa . system:anyuser rl
mkdir private
fs sa private system:anyuser none
mv config id_??? known_hosts private
ln -s private/* .
% ls -l
total 3
-rw-r--r--  1 rees  staff   828 Nov 16  2005 authorized_keys
lrwxr-xr-x  1 rees  wheel    14 Jan  1  1999 config -> private/config
-rw-r--r--  1 rees  wheel    31 Jan  1  1999 environment
lrwxr-xr-x  1 rees  wheel    14 Oct 13  2000 id_dsa -> private/id_dsa
-rw-r--r--  1 rees  wheel   604 Oct 13  2000 id_dsa.pub
lrwxr-xr-x  1 rees  wheel    14 Jun 30  2003 id_rsa -> private/id_rsa
-rw-r--r--  1 rees  staff   224 Jun 30  2003 id_rsa.pub       
lrwxr-xr-x  1 rees  wheel    19 Mar  7  1997 known_hosts -> private/known_hosts
drwxr-xr-x  2 rees  wheel  2048 Nov  1 15:26 private

~/.ssh/environment:
XAUTHORITY=/tmp/Xauthority_put_your_uid_or_uniqname_here

~/.ssh/config:
Host myserver1 myserver2 (list all your k5/keytab servers here)
ForwardX11 yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

/etc/kerberosV/krb5.conf:
[appdefaults]
        afs-use-524 = 2b
        no-addresses = true
[libdefaults]
        forwardable = true

Server (sshd) Side Setup

/etc/ssh/sshd_config:
StrictModes no
GSSAPIAuthentication yes
X11Forwarding yes
PermitUserEnvironment yes

You also need a keytab on the server, typically in /etc/kerberosV/krb5.keytab. That's a necessary nuisance. Generate it something like this:

# kadmin -p admin/admin
kadmin: addprinc -randkey host/<machine.name>@YOURREALM.EDU
kadmin: ktadd -k /etc/kerberosV/krb5.keytab host/<machine.name>@YOURREALM.EDU
kadmin: quit

Then on the client side, you need to kinit before you ssh, and on the server side you need to arrange for afslog (heimdal) or aklog (MIT) to run. I put it in ~/.cshrc:

  if ($?SSH_CLIENT && $?KRB5CCNAME && -d /afs/umich.edu) then
    if (-f /etc/kerberosV/krb5.keytab && -x /usr/bin/afslog) then
      /usr/bin/afslog
    else if (-x /usr/local/bin/aklog) then
      /usr/local/bin/aklog
    endif
  endif

If you use pam (I don't), pam-afs-session can take care of the ticket->token translation for you, so you don't have to run afslog. It also gets a new pag for your session and does other nice things.

Troubleshooting

If it's not working, try "ssh -v". You should see a line like this:

Authentications that can continue: publickey,gssapi-with-mic,password,keyboard-interactive
Next authentication method: gssapi-with-mic
Delegating credentials
Authentication succeeded (gssapi-with-mic).

If you don't see "gssapi-with-mic" in there, then your ssh doesn't support kerberos, you don't have a ticket, you don't have GSSAPIAuthentication turned on in your config file, or something else is preventing kerberos authentication from working.

After you ssh to the server, if you don't have an afs token, there are some other things to check. Try "klist" on the client side. You should see your kerberos ticket. If not, you forgot to kinit. Try "klist" on the server side. You should see your kerberos ticket. Try "tokens" on the server side. If you have a ticket but no token on the server side, you forgot to afslog or aklog.

Related Work

Date: Tue, 4 Dec 2007 15:39:56 +0100 (MET)
From: Rainer Laatsch
Subject: [OpenAFS] Added token passing to SSH protocol 2
To: openafs-info@openafs.org

Patches to enhance openssh-4.7p1 for AFS token and KRB5 ticket passing
in protocol 2 can be found in
 /afs/rrz.uni-koeln.de/admin/public/openssh-4.7p1-PatchDir/
These also allow AFS token passing in protocol 1 for backward compatibily.

Users can do single sign on with an ssh key in protected AFS space.
No rearrangement to the location of the 'authorized_keys' file is needed.

Jim Rees