keyboard-interactive

Bryan Chua chua at ayrnetworks.com
Wed Jan 9 07:07:52 EST 2002


Nicolas Williams wrote:

> On Tue, Jan 08, 2002 at 03:29:36PM +1100, Damien Miller wrote:
> 
>>On Tue, 2002-01-08 at 10:48, Mark D. Roth wrote:
>>
>>>The PAM module itself can't force a particular SSH auth method, but
>>>you can set this up in the sshd_config file by enabling
>>>ChallengeResponseAuthentication and disabling all the other auth
>>>methods.  To get ChallengeResponseAuthentication to use PAM, you also
>>>need to enable PAMAuthenticationViaKbdInt.
>>>
>>I have been wanting to rewrite the PAM kbd-interactive support for a
>>while now, but have hit a brick wall with the PAM api.
>>
>>The PAM API wants to ask all the questions and gather all the responses
>>in a single conversation function. This doesn't work well with the SSH
>>protocol, where userauth messages can arrive in any order. 
>>
>>The current kbd-int PAM support assumes that it can get a response
>>immediately and somewhat abuses the dispatch API to get at it. It
>>probably isn't robust in the face of clients who send requests in a
>>funny order.
>>
>>If any PAM experts can offer a solution to this, it would be greatly
>>appreciated.
>>

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

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

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.

Or am I completely misunderstanding?

-- bryan




More information about the openssh-unix-dev mailing list