Question on the SSH-2 standard

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
    I am getting stuck trying to understand the nuances of the SSH-2
standard in a number of cases. For instance, in section 7 of RFC 4252,
when describing the client's response to an SSH_MSG_USERAUTH_PK_OK packet
received from the server, the RFC reads:

    "To perform actual authentication, the client MAY then send a
signature generated using the private key.  The client MAY send the
signature directly without first verifying whether the key is

    So, since the client just MAY send a signature, what happens if
it doesn't? My assumption is that the authentication won't be successful,
and that the server will just drop the connection. Is this correct?

Re: Question on the SSH-2 standard

Quoted text here. Click to load it

At this point in the protocol, the server is expecting to receive a
stream of SSH_MSG_USERAUTH_REQUESTs, using whatever methods the
client feels like trying, until either one is successful or the
client gives up.

So, the client has just sent an SSH_MSG_USERAUTH_REQUEST which is of
the special type `don't actually try to authenticate but tell me in
principle whether you'd accept a signature from this key if I
provided one'. The server responds to this by sending one of
back in the loop where it's expecting to receive another
SSH_MSG_USERAUTH_REQUEST. So if the server OKs the use of this
public key in principle, then the client will _probably_ want to
follow that up with a SSH_MSG_USERAUTH_REQUEST specifying
"publickey" and this time providing a real signature.

But it doesn't _have_ to (hence MAY); it isn't deemed to have
committed itself to sending that _particular_ type of
SSH_MSG_USERAUTH_REQUEST just because it asked whether it could. It
could, if it so wishes, change its mind at this point, and send a
SSH_MSG_USERAUTH_REQUEST for some totally other method (such as
"password"), or using a completely different key. Or it could even
drop the connection from the client side.

A plausible scenario for how this could happen might be:

 - user tells client to authenticate using a private key
 - client reads the unencrypted public half of the key and asks the
   server if it's willing to accept that key
 - server says yes (SSH_MSG_USERAUTH_PK_OK)
 - client then asks the user for their passphrase so it can decrypt
   the private half of the key and construct the signature
 - user, after several attempts, turns out to have forgotten
   passphrase, and asks client to abandon public-key authentication
   and fall back on password
 - client asks user for password, and submits an
   SSH_MSG_USERAUTH_REQUEST with method "password"
 - server is unfazed, and proceeds with password authentication.

Quoted text here. Click to load it

No. Why would the server drop the connection? It's sitting there in
a loop waiting to receive another SSH_MSG_USERAUTH_REQUEST. It might
eventually give up if the client sits there doing nothing for ever
and doesn't send one, and it would certainly have grounds to drop
the connection if the client started sending the sort of messages
that presupposed the authentication phase was complete, but after
it's just sent SSH_MSG_USERAUTH_PK_OK it's still simply waiting for
the client to attempt authentication.
Simon Tatham         What do we want?        ROT13!

Re: Question on the SSH-2 standard

    Thanks, that was very useful feedback.

Site Timeline