[OpenAFS-devel] OpenAFS and OpenSSH, PAM, tokens

Douglas E. Engert deengert@anl.gov
Thu, 02 Nov 2006 13:27:06 -0600


Jeffrey Hutzelman wrote:

> 
> 
> On Tuesday, October 31, 2006 09:01:07 AM -0600 "Douglas E. Engert" 
> <deengert@anl.gov> wrote:
> 
>> Rather then having to modify ssh to swap the order of the
>> calls to pam_setcred and pam_open_session, you could look at
>> using one of the pam_afs module that will get the token and PAG
>> during the pam_setcred. For example the pam_openafs_session.so
>> module can be called from "auth" and it will get the token
>> during pam_setcred.
> 
> 
> The PAM module that ships with OpenAFS does this.  However, rather than 
> reusing whatever password 

Password? I thought we are talking K5, where the K5 ticket is obtained
either via pam_krb5, or via delegated GSSAPI credential as sshd does,
so AFS only needs the location of the ticket cache.


> the user most recently typed, it uses the same 
> password with which the auth module successfully obtained a token.  This 
> is entirely reasonable, because PAM does not call the setcred methods of 
> modules whose authenticate method did not succeed.
> 
> However, ssh runs the authenticate operation in a separate process, with 
> no opportunity to communicate that password to the setcred method.  We 
> call back into the PAM framework to set a module-specific data item, but 
> then when we return, the process exits, taking our data with it.

I must admit that when I did compile OpenSSH on Solaris <= 5.9, HP_UX and
on Linux I used the UNSUPPORTED_POSIX_HACK. With Solaris 10 and Ubuntu
we are using the vendor's sshd.

With gssapi as Simon points out sshd does not call pam_setcred.

> 
> The OpenAFS PAM module does nothing at all in pam_open_session, so the 
> relative order of calls to setcred and open_session does not matter. 
> However, the order in which they are called with respect to other 
> operations may be relevant.


If I was to integrate pam_afs2 into the AFS source tree would it be
considered for inclusion?

Some features:

   * expects krb5 ticket cache is available via KRB5CNAME in pam_env.
     On a system like HP_UX which does not have pam_env, it can derive
     the name.

   * Getting the pag is optional. Useful from xscrensaver or gnome-screensaver
     to renew the token when the screen is unlocked.

   * It has no krb5 code, but fork/execs your favorite aklog to get token.

   * The tokens/PAG can be obtained at pam_setcred or pam_open_session,
     Thus can be used with different applicaitons/systems that call
     pam in unusual ways.

   * is independent of pam_afs, so the admin could use either.

> 
> 

-- 

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