keyboard-interactive

Nicolas Williams Nicolas.Williams at ubsw.com
Fri Jan 11 00:23:41 EST 2002


On Wed, Jan 09, 2002 at 09:48:07PM -0600, Mark D. Roth wrote:
> On Wed Jan 09 23:21 2002 +0100, Markus Friedl wrote:
> OK, so how about this:
> 
>  * Call the main loop from the PAM conversation function with some
>    state telling it where it was called from.

Bingo. Make the mainloop reentrant.

>  * When the main loop gets the next message from the client, it can
>    return control to the PAM conversation function.

OR perhaps the mainloop can return to the conversation function only if
it's an INFO_RESPONSE message. Else, if handling continues as you
suggest then kbd-interactive messages can't be interleaved with any
others; whether or not sshd should work that way depends on the
protocol drafts.

>  * If the client sent an INFO_RESPONSE message, the PAM conversation
>    function returns the client's response, and the PAM transaction
>    continues normally.
> 
>  * If the client sent some other type of message, the conversation
>    function can return PAM_CONV_ERR to abort the PAM transaction.  It
>    should also set some state to indicate that the PAM transaction was
>    aborted.
> 
>  * When pam_authenticate() returns, if the transaction was aborted,
>    return control to the main loop to handle the request that the
>    client sent.
> 
> There are some obvious semantics to be worked out in terms of how the
> state is maintained, but the PAM code itself would be fairly
> straightforward.  Or is there something I'm missing here?

See above.

> -- 
> Mark D. Roth <roth at feep.net>
> http://www.feep.net/~roth/


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