keyboard-interactive

Nicolas Williams Nicolas.Williams at ubsw.com
Wed Jan 9 09:32:31 EST 2002


On Tue, Jan 08, 2002 at 12:07:52PM -0800, Bryan Chua wrote:
> > On Tue, Jan 08, 2002 at 03:29:36PM +1100, Damien Miller wrote:
> >>What I would really like to see in PAM is the ability call to a function
> >>to collect the auth queries and another to send the responses at a time
> >>of my choosing.
> 
> According to what I am interpreting from kbdinteract-02, the protocol 
> sequence is defined to be specifically in section 3 - Protocol 
> Exchanges, to be USERAUTH_REQUEST -> INFO_REQUEST -> INFO_RESPONSE.  At 
> least within kbdinteract, there do not appear to be any issues with 
> respect to asynchronous kdbinteract responses, so it should be safe for 
> the conversation function to post a single query to the client and await 
> a single response.  As long as the conversation function is sufficiently 
> generic, it should be able to support any number of such query/response 
> exchanges.  Of course, it would be wise to set up the conversation 
> timeout, otherwise the system would thus be exposed to a distributed DoS 
> from several clients with open auth states in the middle of a blocking 
> function....

Also, if a module posts multiple questions to the conversation function
then sshd should (but doesn't have to) post those multiple questions in
one info request.

Looks like kbdinteract was written with PAM in mind by folks who have
lots of experience with PAM (Frank Cusack, Martin Forssen) so that the
INFO_REQUEST/INFO_RESPONSE messages are defined to look much like a
straight encoding of PAM conversation messages/responses.

> Perhaps the question to be considering is not how to map the SSH 
> messages into a PAM structure, but how to map a PAM structure into SSH 
> messages.  After all, the whole point of building a robust PAM 

There can only be one userauth request going at any given time, yes? If
so, then you map a single SSH connection to a single PAM handle and
back, and, since OpenSSH is single-threaded, with one connection
per-sshd-process, you can just have one PAM handle global to sshd
(though a single global PAM handle is not not what *I* would use, but
then, I'm not an OpenSSH developer).

> converstaion function is to make the system easier to use tor module 
> developers, no?  I believe the exercise is to loop through the PAM msg 
> array and build a SSH_MSG_USERAUTH_INFO_REQUEST packet, send it, and 
> then block waiting for the response, after which the responses may be 
> filled in to the reply array.

Bingo.

> Where I originally got stuck was in looking at the difference between 
> INITIAL_LOGIN and *else*, where stdio or a pipe-equivalent is already 
> established, so a packet must be constructed.

Huh? I don't get this.

> Or am I completely misunderstanding?

No, you understood the intent of the kbdinteract draft just fine,
methinks. Ask the authors, if anything. I know that Frank understands
PAM quite well, so he certainly can speak to any issues you may have.

> -- bryan


Cheers,

Nico
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.




More information about the openssh-unix-dev mailing list