Re: Login failure with libssh2-1.2.2 and SuSE Enterprise 10 Linux

On Dec 14, 2009, at 6:41 PM, Daniel Stenberg wrote:

> On Mon, 14 Dec 2009, Dave McCaldon wrote:
>
>> I think I've found the problem. It seems we're asking for an ssh-connection method "password" and this server doesn't seem to allow password. Note that regular [OpenSSH] ssh asks for keyboard-interactive.
>
> AFAIR, regular openssh asks for many different authentications one by one. If configured to do so at least.

If you run regular ssh with -v, you'll see it try different methods:

debug1: Authentications that can continue: publickey,keyboard-interactive
debug3: start over, passed a different list publickey,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/davem/.ssh/identity
debug3: no such identity: /Users/davem/.ssh/identity
debug1: Trying private key: /Users/davem/.ssh/id_rsa
debug3: no such identity: /Users/davem/.ssh/id_rsa
debug1: Trying private key: /Users/davem/.ssh/id_dsa
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '/Users/davem/.ssh/id_dsa':
debug2: no passphrase given, try next key
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:
debug3: packet_send2: adding 32 (len 20 padlen 12 extra_pad 64)
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 0
debug3: packet_send2: adding 48 (len 10 padlen 6 extra_pad 64)
debug1: Authentication succeeded (keyboard-interactive).

According to the RFC4252 the server is supposed to respond as follows (for a rejection):

5.1. Responses to Authentication Requests

   If the server rejects the authentication request, it MUST respond
   with the following:

      byte SSH_MSG_USERAUTH_FAILURE
      name-list authentications that can continue
      boolean partial success

Looking back at the libssh2 trace, I can see the server responding with:

=> libssh2_transport_read() plain (36 bytes)
0000: 33 00 00 00 1e 70 75 62 6c 69 63 6b 65 79 2c 6b 3....publickey,k
0010: 65 79 62 6f 61 72 64 2d 69 6e 74 65 72 61 63 74 eyboard-interact
0020: 69 76 65 00 ive.

However, with the current API there's no way to communicate back to the application that there are additional authentication methods available. I suppose that I could enhance my previous patch to return LIBSSH2_ERROR_AUTHORIZATION_FAILED if there are no items in the "authentications that can continue" field, otherwise return a new error LIBSSH2_ERROR_AUTHORIZATION_FAILED_TRY_OTHER_METHODS which could give an indication to the application that it can try a different authentication method (although not which ones might work).

>> The application code isn't designed to be "driven" by a user, so keyboard-interactive didn't seem the right function to use. The question is, is this just a sshd configuration problem? Or should I be using libssh2_userauth_keyboard_interactive_ex() and then writing a callback function that simply returns the password as supplied by the app?
>
>> From a program's point of view, password and keyboard-interactive really
> aren't very different. At least from what I understand after having quickly glanced over what the docs say (http://www.ietf.org/rfc/rfc4252.txt and http://www.ietf.org/rfc/rfc4256.txt). I figure your application could just as well try both, one at a time.

It looks like the key difference between password and keyboard-interactive is that with password you send a username and password and either get logged in, or rejected (once and for all). However, keyboard-interactive requires that the client send the username first, followed by the server responding with 0 or more challenge-response requests.

From a program point of view, keyboard-interactive is a bit more subtle, if you look at the SSH_MSG_USERAUTH_INFO_REQUEST structure that the server responds with, you can see that there is no field named "password". In fact when you log in, the "Password:" prompt is from the server -- it could just as easily be "Mother's maiden name:".

3.2. Information Requests

   ...

   The SSH_MSG_USERAUTH_INFO_REQUEST message is defined as follows:

      byte SSH_MSG_USERAUTH_INFO_REQUEST
      string name (ISO-10646 UTF-8)
      string instruction (ISO-10646 UTF-8)
      string language tag (as defined in [RFC-3066])
      int num-prompts
      string prompt[1] (ISO-10646 UTF-8)
      boolean echo[1]
      ...
      string prompt[num-prompts] (ISO-10646 UTF-8)
      boolean echo[num-prompts]

The response back to the server looks like:

3.4. Information Responses

   After obtaining the requested information from the user, the client
   MUST respond with an SSH_MSG_USERAUTH_INFO_RESPONSE message.

   The format of the SSH_MSG_USERAUTH_INFO_RESPONSE message is as
   follows:

      byte SSH_MSG_USERAUTH_INFO_RESPONSE
      int num-responses
      string response[1] (ISO-10646 UTF-8)
      ...
      string response[num-responses] (ISO-10646 UTF-8)

So I'm going to conclude that this is in fact a server configuration issue -- it needs to allow the "password" authentication method in order to be properly driven by the application.

Of course now I need to look at supporting keyboard-interactive in the app (perhaps a dictionary of challenge/response values) because I'm sure I'll get some push back on this.

Thanks!

_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2009-12-15