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

[Jeffrey Hutzelman]

On Tue, 31 Oct 2006, Simon Wilkinson wrote:

> OpenSSH, without POSIX_THREADS, will work with AFS, providing you use
> an AFS PAM module which creates the PAG as part of the session or
> setcred sections - we use Doug Engerts pam_afs2 here, which works
> fine. You need to do this, anyway, if you want to get AFS credentials
> following a successful GSSAPI authentication.

OpenAFS's PAM module does nothing during open_session, and while it will
create the PAG during setcred, it doesn't set a token there unless it can
actually obtain tokens using the password stored for it (in PAM data) by
the auth method.  That is, OpenAFS's authenticate and setcred operations
need to communicate with each other, and OpenSSH prevents that by running
the former in a subprocess.

In general, OpenAFS's PAM module fails to do quite a number of things that
are necessary to work around ill-behaved PAM applications.  Most people
are better off with a good pam_krb5, pam_krb5_afs, and possibly an AFS
session module to establish PAG's.


> The POSIX_THREADS hack appears to be being deprecated in the OpenSSH
> codebase - it's now renamed USE_UNSUPPORTED_POSIX_THREADS_HACK.

The support level hasn't changed - they've always thought it was an evil
unsupported hack.  According to the changelog, the name changed because
too many people were asking questions about it. :-)

> [ The issue is that OpenSSH's complex 'monitor' system means that the
> authentication sections of the PAM stack are run within a process
> which has no relationship to the process eventually used to spawn the
> shell ]

Right.  Details follow for those who are interested...


The problem here is that PAM modules can call back to the application to
send messages to and prompt for input from the user.  This doesn't fit
well with OpenSSH's event-driven model, where the idle time is spent in
the top-level packet dispatcher, which calls into appropriate code to
handle each incoming packet.  To work around this, the OpenSSH people call
pam_authenticate from a subprocess, which communicates with the main ssh
process via simple protocol.  This way, the conversation function can send
a message or request to the main sshd, then block waiting for the
response, while sshd returns to the dispatcher to handle another packet.
The POSIX_THREADS hack makes pam_authenticate run in a separate thread
rather than in a separate process.  It works, but like the original
solution, it's not very clean.

There is a correct solution to this, which is to use PAM_CONV_AGAIN.
However, Google shows that back in 2001 Damien Miller asked the PAM list
how to deal with this issue, and got back the answer that it wasn't
realistic to use PAM_CONV_AGAIN because not all modules supported it.
Perhaps things have changed since then, and a patch to do this right would
be well-received.  Who knows?

-- Jeff