[OpenAFS] ssh and afs

Ray Link rlink+@pitt.edu
Sat, 04 May 2002 14:34:09 -0400 (EDT)


There is a way to do this with the newer versions of OpenSSH, but it
involves dorking with the structure of your ~/.ssh directory.

Background info first:

In older (pre-2.9, iirc) versions of OpenSSH, it would pass your AFS
token across during the authentication phase, so the remote sshd could
read your ~/.ssh/authorized_keys file (since the whole directory is
hopefully ACL'd to keep people out, as your private keys live there,
too.)  Now that the remote sshd can read files in your ~/.ssh dir, RSA
key authentication can happen normally, and all is good.

Currently, however, OpenSSH doesn't accept passed AFS tokens until
after authentication has already taken place.  Since the remote sshd
doesn't have a token to read your aurthorized_key file, it falls back
to password auth.  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.

And now, on to the workaround.  (ssh1 and RSA auth used in this example)

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.

So 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
with nothing but "<you> rliwdka" that contain those private keys.

So here's what happens now:

You attempt an ssh 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 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.

Yes, it sucks, but it works, and doesn't compromise your private keys.
Getting all of your users to do this is another story...

On Fri, 3 May 2002, Derek Atkins wrote:

> Um, I think the answer is: you don't.
>
> -derek
>
> Mitch Collinsworth <mitch@ccmr.cornell.edu> writes:
>
> > To clarify, the question Daniel was asking is how to do this when
> > you're still running kaserver.
> >
> > -Mitch
> >
> >
> > On 3 May 2002, Derek Atkins wrote:
> >
> > > Use krb5 and v5-TGT passing.  Then use pam-openafs-session to convert
> > > your v5 TGT into an AFS tokens (via aklog).
> > >
> > > -derek
> > >
> > > Daniel Blakeley <daniel@ccmr.cornell.edu> writes:
> > >
> > > > Hi,
> > > >
> > > > We're having some problems integrating openssh with AFS.  We want
> > > > users to login to one machine and be able to login to other machines
> > > > in the cell without typing a password and they should have an AFS
> > > > token.  The lastest version of openssh doesn't seem to pass tokens
> > > > like the version 1.x did.  We are running the kaserver but Krb5 is not
> > > > far in the future.  What is the proper way to have a single sign on
> > > > with a recent version of openssh?
> > > >
> > > > Thanks,
> > > > - Daniel
> >
>
>

==== Ray Link === University of Pittsburgh CSSD === rlink@pitt.edu ====

"When in doubt, parenthesize. At the very least it will let some poor
schmuck bounce on the percent key in vi."
		    -Larry Wall