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
