Question on the SSH-2 standard - SSH

This is a discussion on Question on the SSH-2 standard - SSH ; 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 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Question on the SSH-2 standard

  1. Question on the SSH-2 standard

    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
    acceptable."

    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?


  2. Re: Question on the SSH-2 standard

    K. Jennings wrote:
    > "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
    > acceptable."
    >
    > So, since the client just MAY send a signature, what happens if
    > it doesn't?


    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.

    > My assumption is that the authentication won't be successful,
    > and that the server will just drop the connection. Is this correct?


    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!
    When do we want it? ABJ!

  3. Re: Question on the SSH-2 standard

    Thanks, that was very useful feedback.


+ Reply to Thread