OpenSSH, OpenAFS, Heimdal Kerberos and MIT Kerberos
Douglas E. Engert
deengert at anl.gov
Tue Jan 27 04:21:48 EST 2004
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 its simplest form, all that is needed is:
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:
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.
Douglas E. Engert <DEEngert at anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
More information about the openssh-unix-dev