[OpenAFS-devel] OpenSSH, OpenAFS, Heimdal Kerberos and MIT Kerberos

Andrei Maslennikov andrei at caspur.it
Tue Jan 27 05:43:46 EST 2004


We have implemented the strategy similar to the one that Douglas suggested
in his posting. In our case (Heimdal) we allow user to login using his/her
K5 password and then call Heimdal "afslog" inside session.c:

        system("/usr/sshutils/sbin/afslog >/dev/null 2>&1");

A small complementary trick (sshd is invoked via inetd/xinetd with "-i"
flag from within the pagsh wrapper) allows the token to be obtained
automatically in a brand-new pagsh. All this works with the protocol 2,
and users obtain both K5 tickets and PAG-based tokens upon login. Apart
from just one extra system call, no code hacking is needed for OpenSSH.

What we were yet unable to achieve is the further K5 credentials
forwarding in case of login via the K5 password. What happens is the
following:

  1) ssh to host A, login with K5 password (and obtain a PAG-based token)
  2) from host A, ssh to host B, login w/o pw (this time with GSSAPI)
  3) inside host B: no K5 creds forwarded from host A, no token. 

A possible workaround would be to re-authenticate automatically with
GSSAPI right after the successful K5 password login (using the
just-obtained K5 creds), but it might be tricky to implement. There is
even a comment in the auth2.c ("/* XXX todo: check if multiple auth
methods are needed */), but nobody ever went further. If this would work,
the GSSAPI creds would be stored on host A and then presumably forwarded
to the host B during the GSSAPI login (and hence the AFS token would be
obtained there automatically). I.e. it could become possible to type in
the password only one time, and then navigate with ssh between enabled
machines without password - all this while preserving K5 creds and
automatically obtaining AFS tokens.

Andrei.


On Mon, 26 Jan 2004, Douglas E. Engert wrote:

> Rather then implementing kafs in MIT Kerberos, I would like to suggest
> an alternative which has advantages to all parties.
> 
> The OpenSSH sshd needs to do two things: 
>    (1) sets a PAG in the kernel, 
>    (2) obtains an AFS token storing it in the kernel.
> 
> It can use the Kerberos credentials either obtained via GSSAPI
> delegation, PAM or other kerberos login code in the sshd.
> 
> The above two actions can be accomplished by a separate process, which
> can be forked and execd by the sshd and passed the environment which may
> have a KREB5CCNAME pointing at the Kerberos ticket cache Other
> parameters such as the home directory could also be passed.
> 
> 
> This would then allow simple code in OpenSSH that does not depend on
> OpenAFS, Hiemdal or MIT code to fork/exec the process that does all the
> work. This would be called by the process that would eventially become
> the user's shell process and is run as the user.
> 
> OpenSSH could be built on systems that may or may not have AFS installed
> and run on a system with or without AFS.  The decision is based on the
> existence of the executable and any options in sshd_config.
> 
> In its simplest form, all that is needed is:
> 
>   system("/usr/ssh/libexec/aklog -setpag") 
> 
> This is a little over simplified as there should be a test if the
> executable exists, processing of some return codes, making sure the
> environment is set, setting some time limit. etc. But the point is there
> is no compile dependence on OpenAFS, MIT or Hiemdal by the OpenSSH sshd,
> and any failure of the process will not effect the sshd.
> 
> 
> 
> We have been using something like this for years which issues a syscall
> to set a PAG for the current process, then fork/exec ak5log.  Our
> current mode to OpenSSH in session.c is as simple as:
> 
>   krb5_afs_pag_env(NULL, env);
> 
> It is currently built with the MIT Kerberos code for historic reasons,
> but could be seperate as it has no real dependency on the MIT code. 
> 
> I would hope that the members of the OpenSSH community who use OpenAFS,
> Hiemdal and/or MIT could agree on a simple command line interface that
> would encourage the builders of OpenSSH to always have this enabled.
> 
> 





More information about the openssh-unix-dev mailing list