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

[Douglas E. Engert]

Andrei Maslennikov wrote:
> 
> 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");

Yes this is just the type interface that could simplify the OpenSSH code.
What the OpenAFS comunity needs to decied is what is needed for the
common interface. 

> 
> 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.

Nice trick. But if the AFS kernel code supports -setpag by the afsklog
or aklog to set the parent's prooces this would not be needed.   

> 
> 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)

Was the ticket marked forwardable?  Can you set with Hiemdal in the
krb5.conf file a default that tickets should be forwardable? 
What does klist -f show on host A?


>   2) from host A, ssh to host B, login w/o pw (this time with GSSAPI)

GSSAPI should have delegated a K5 credential, and set the KRB5CCNAME
on host B. 

>   3) inside host B: no K5 creds forwarded from host A, no token.

We can do the above but normally get the initial ticket on the local 
workstation at login or via kinit. We try not to require uses to ever 
send thier Kerberos password over the network. 

But in our case we let PAM on A get the ticket and are using the 
MIT Kerberos. Can you set with Hiemdal in the krb5.conf file a default 
that tickets should be forwardable? 

> 
> 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.
> >
> >

-- 

 Douglas E. Engert  <DEEngert at anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444