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:

There are several problems with this approach:

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


Host myserver1 myserver2 (list all your k5/keytab servers here)
ForwardX11 yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

        afs-use-524 = 2b
        no-addresses = true
        forwardable = true

Server (sshd) Side Setup

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/<>@YOURREALM.EDU
kadmin: ktadd -k /etc/kerberosV/krb5.keytab host/<>@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/ then
    if (-f /etc/kerberosV/krb5.keytab && -x /usr/bin/afslog) then
    else if (-x /usr/local/bin/aklog) then

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.


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

Patches to enhance openssh-4.7p1 for AFS token and KRB5 ticket passing
in protocol 2 can be found in
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