How exactly is signature verification done in SSH v2 authentication?

One of the authentication methods in SSH involves the client signing a message with its private key and sending it to the server for verification.

RFC 4252 (page 9) says:

The value of 'signature' is a signature by the corresponding private
key over the following data, in the following order:

string    session identifier
byte      SSH_MSG_USERAUTH_REQUEST
string    user name
string    service name
string    "publickey"
boolean   TRUE
string    public key algorithm name
string    public key to be used for authentication


The same RFC (page 8) says that all the above information other than the session identifier is passed to the server along with the signature. To verify the signature then, the server would have to recontruct the message (adding the session identifier) and then pass it on to the signature verification algorithm, alongside the received signature and public key.

Is this what happens?

• Just to clarify that this isn't a part of you question, did you mean to say that it involves the client signing a message with its private key? Assuming that was just a typo, is your question whether in practice the server has to reconstruct the message before verifying it? I guess I'm just a bit unclear on which aspects of this you are debating. – thesquaregroot Jul 15 at 20:58
• @thesquaregroot Yes, I meant private key, not public key. Have edited the question now. Also, yes.. I want to know whether the server has to recontruct the message before verifying it – Daud Jul 15 at 21:07

Yes, the server reconstructs the signature pre-image and then verifies that the signature is valid.

From a purely protocol perspective, I think you effectively answered your own question - the protocol defines the format with which the signature is sent to the server and it doesn't contain the session identifier. On page 1 it mentions:

When this protocol starts, it receives the session identifier from the lower-level protocol (this is the exchange hash H from the first key exchange). The session identifier uniquely identifies this session and is suitable for signing in order to prove ownership of a private key. This protocol also needs to know whether the lower- level protocol provides confidentiality protection.

This means that not only does the server already have the session identifier, but is specifically using it to connect the communication channel that is being authenticated to the private key. Since this exchange hash is secret but tied to the current communication channel (as described in RFC 4432), it makes sense to be cautious about sending it unnecessarily.

Regardless, from a protocol perspective this is sufficient evidence that the signature pre-image must be reconstructed. But for what it's worth, this can also be seen in the OpenSSH source code where the buffer, b, is constructed using a series of sshbuf_put_* operations and then ultimately passed into sshkey_verify.

• So, everything other than the session identifier is taken from the client for re-creating the message, right? – Daud Jul 16 at 4:48
• @Daud Yes, though the rest of the data is pretty static for a given user/public key. – thesquaregroot Jul 16 at 14:10