OpenSSH, OpenAFS, Heimdal Kerberos and MIT Kerberos

[Henry B. Hotz]

I don't disagree with your proposal at all.  Sounds good.  It should 
make it easier to fix/change things in the future.

But. . .

Isn't the reason this keeps coming up that AFS client doesn't 
(can't?) behave like a normal Kerberos application and just get it's 
own service ticket when it needs one (based on an existing tgt)?  The 
real reason this doesn't happen is that tickets are stored in a file 
in /tmp, but it's a different set of file system code inside the 
kernel that would need to access it to request the service ticket.

Can't we figure a way to just make the kernel module get the service 
ticket (token) automatically, or fail if there is no tgt?  That would 
make the whole problem go away and AFS would no longer need the 
special attention it does now.

I note that on MacOS X tickets are stored in a MACH "security 
context" which acts a lot like a PAG.  Furthermore it's accessible 
inside the kernel.  Doesn't Windows have some similar in-memory 
storage mechanism?

Has anyone thought about how congruent PAGs and terminal sessions 
are?  I think X11 defined the latter, and Kerberos has tried to tie 
in to them rather than import the PAG concept.

At 11:21 AM -0600 1/26/04, 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.   
>
>--
>
>  Douglas E. Engert  <DEEngert at anl.gov>
>  Argonne National Laboratory
>  9700 South Cass Avenue
>  Argonne, Illinois  60439
>  (630) 252-5444


-- 
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu