Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
- Question on the SSH-2 standard
- K. Jennings
June 2, 2007, 3:47 am
rate this thread
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
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
SSH_MSG_USERAUTH_PK_OK or SSH_MSG_USERAUTH_FAILURE, and then it's
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
(SSH_MSG_USERAUTH_REQUEST, "publickey", FALSE)
- 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.
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!
- » ssh on command line: force using a group size (prime size) of 1024 (and no...
- — Newest thread in » Secure Shell Forum