problem with pam_converse with openssh protocol version 1

[Darren Tucker]

Frank Cusack wrote:
> On June 21, 2005 5:55:05 PM +0200 Marcin Mogielnicki <mar_mog at o2.pl> wrote:
> 
>> I suspect that I will receive very simple answer - "use v2 only".
>> It is the simplest and the most secure and effective, but
>> inacceptable. Some of machines (Cray SV1 for example) have v1 only 
>> implemented. Besides hundreds of users connect to my site every day
>> - try to persuade all of them to use v2 only.
>>
>> So one more time:
>>
>> 1) if ChallengeResponseAuthentication is set to yes, pam conversation 
>> works right with v2, but v1
>> returns PAM_CONV_ERR. Moreover, it asks user for weird things, which 
>> make user to call me.
>> 2) if ChallengeResponseAuthentication is set to no, pam conversation 
>> takes no place in v1 and v2
>> - PAM_CONV_ERR is returned by sshd to pam module.
>>
>> Is there any way to implement pam conversation into v1 protocol? If
>> not, it could be nice for v1 to converse with user in more
>> comprehensible way.

If already is however it is limited by the protocol, see below.

> In v1, you'd have to use TIS authentication. You have to make sure
> your client doesn't echo the password, though. (I think all modern
> clients are conservative and don't echo.) You might end up having to
> make some small sshd changes to make this work.

That's what was being attempted first but it failing.

Note that in this particular PAM configuration there are 2 calls to the 
conversation function, once for PIN and once for password,.  When that 
fails, it's falling back to plain password authentication (you can 
prevent that by disabling PasswordAuthentication in sshd_config since 
it's probably not going to work with that PAM config anyway).

My read of the original SSH1 protocol spec is that there is only one 
challenge/response pair permitted by the protocol.  For the TIS 
response, it says:

    41 SSH_CMSG_AUTH_TIS_RESPONSE

         string   user response to tis challenge

         When client receives SSH_SMSG_AUTH_TIS_CHALLENGE and ask users
         response to challenge it sends it back this message. The server
         answers with SSH_SMSG_FAILURE or SSH_SMSG_SUCCESS.

so the server can only reply with success or failure immediately after 
the first response, there's no partial-success flag.

If you can compact your requirements to a single challenge and response 
(eg "Enter password followed by PIN:") it'll probably work, but other 
than that I think you're limited to Protocol 2 only.

[1] http://www.zip.com.au/~dtucker/openssh/ssh-rfc-v1.txt among other 
places.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.