ssh-1.2.26 + arla 0.9 + kth krb4-0.9.9

[Dr A V Le Blanc]

Previously Doug Song has suggested that I make the following
change in auth-passwd.c after adding his AFS patch:

diff -ru2N ssh-1.2.26/auth-passwd.c ssh-MCC/auth-passwd.c
--- ssh-1.2.26/auth-passwd.c	Wed Aug 19 14:02:53 1998
+++ ssh-MCC/auth-passwd.c	Wed Aug 19 14:02:28 1998
@@ -672,4 +672,5 @@
 	phost[INST_SZ-1] = NULL;
 	
+#ifndef AFS
 	/* Now that we have a TGT, try to get a local "rcmd" ticket to
 	   ensure that we are not talking to a bogus Kerberos server. */
@@ -709,4 +710,5 @@
 	}
 	
+#endif
 	/* Authentication succeeded. */
 	return 1;

After recompiling ssh-1.2.26 with the kerberos check in auth-passwd.c
commented out, here is a login session.  It originates from avl0,
which is running MIT's libafs.o module, and it goes to avl, which
is running arla.  Both now have ssh-1.2.26 with the same patches;
indeed, I just copied the binaries over.  Note that both avl and avl0
are running the same version of Debian Linux, though avl0 has a
slightly older kernel to accommodate the MIT libafs.o module.

linux 06:51:54> usr/bin/ssh -v avl
SSH Version 1.2.26 [i486-unknown-linux], protocol version 1.5.
Standard version.  Does not use RSAREF.
linux: Reading configuration data /etc/ssh/ssh_config
linux: ssh_connect: getuid 0 geteuid 0 anon 0
linux: Connecting to avl [130.88.201.63] port 22.
linux: Allocated local port 1011.
linux: Connection established.
linux: Remote protocol version 1.5, remote software version 1.2.26
linux: Waiting for server public key.
linux: Received server public key (768 bits) and host key (1024 bits).
linux: Host 'avl' is known and matches the host key.
linux: Initializing random; seed file /root/.ssh/random_seed
linux: Encryption type: idea
linux: Sent encrypted session key.
linux: Installing crc compensation attack detector.
linux: Received encrypted confirmation.
linux: Remote: AFS token accepted (afs at mcc.ac.gb, AFS ID 102 at mcc.ac.gb)
linux: Trying rhosts or /etc/hosts.equiv with RSA host authentication.
linux: Remote: Rhosts/hosts.equiv authentication refused: client user 'root', server user 'root', client host 'avl0.mcc.ac.uk'.
linux: Server refused our rhosts authentication or host key.
linux: Connection to authentication agent opened.
linux: Trying RSA authentication via agent with 'root at linux'
linux: Received RSA challenge from server.
linux: Sending response to RSA challenge.
linux: Remote: RSA authentication accepted.
linux: RSA authentication accepted by server.
linux: Requesting pty.
linux: Requesting authentication agent forwarding.
linux: Requesting shell.
linux: Entering interactive session.
Last login: Thu Aug 20 06:51:33 1998 from avl0.mcc.ac.uk
You have new mail.
avl 06:55:52 > groups
root
avl 06:55:58 >

Note that though the AFS token is accepted, avl is not creating a
ticket file nor setting a PAG.  I thought perhaps this might be
because I was logging in as root, so I tried with a normal user
name: no better luck.  On the other hand:

avl 07:00:24 > ls /afs/mcc/users/mcc/zlsiial
ls: /afs/mcc/users/mcc/zlsiial: Permission denied
avl 07:02:37 > cd /usr/contrib/packages/kthkrb/bin
avl 07:02:59 > groups
root
avl 07:05:06 > exec ./pagsh
avl 07:05:12 > exec bash
avl 07:05:16 > groups
root 33536 32517
avl 07:05:18 > ./kinit zlsiial
eBones International (avl)
Kerberos Initialization for "zlsiial"
Password:
avl 07:05:30 > ./afslog
avl 07:06:01 > ls /afs/mcc/users/mcc/zlsiial
Address                  crontab.root             non
Afs                      cv                       oldstuff
...
conf                     newissue                 xterm.mk
config                   news
avl 07:07:30 >

So, the krb4 stuff is configured so that the afs part, at least,
works, gets a usable token, and gives access to the files in afs.
And, now that I have recompiled the ssh-1.2.26 on other AFS
machines with the kerberos authentication check omitted, I can
ssh from an arla machine to an AFS machine and (despite the
silly userid in the token) get access to my own files.
This seems to suggest that ssh from ssh-1.2.26 is working correctly,
but that sshd on arla machines is having some sort of problem.
Finally, when I ssh from an arla machine to an arla machine,
having first acquired a PAG and AFS authentication, the new session
does not possess a PAG, but the kerberos tickets are correctly
transferred.

To sum up: with Doug Song's AFS patch and the patch at the top
of this note, I get

from AFS to arla      no new PAG     no token transfer
from AFS to AFS       new PAG        token transfer
from arla to arla     no new PAG     token transfer
from arla to AFS      new PAG        token transfer

     -- Owen
     LeBlanc at mcc.ac.uk