If you are sending an rsa-sha2-XXX signature, you cannot set all 3 fields in the authentication request to "ssh-rsa", because then this makes for a SHA-1 signature as it was done traditionally, not a SHA-2 signature. To send a SHA-2 signature, at least one field has to contain "rsa-sha2-XXX".
The draft specifically says the signature format names are "rsa-sha2-XXX", but the public key format name stays "ssh-rsa", which it must stay in order to preserve existing RSA key fingerprints.
The signature format is defined thus:
string "rsa-sha2-256" / "rsa-sha2-512"
string rsa_signature_blob
These specifications seem to me very clear and unambiguous. In a user authentication request, when sending a SHA-2 signature, the only correct encoding of algorithm names is as follows:
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "publickey"
boolean TRUE
string "rsa-sha2-256" / "rsa-sha2-512"
string public key blob:
string "ssh-rsa"
mpint e
mpint n
string signature:
string "rsa-sha2-256" / "rsa-sha2-512"
string rsa_signature_blob
If your implementation does not encode the algorithm names this way, it is incorrect. The latest OpenSSH versions encode the algorithm names this way, though a previous version used "ssh-rsa" in the third field by mistake.
Bitvise SSH Client encodes the fields this way also, and the current version of Bitvise SSH Server expects the algorithm names this way, and only this way.
I did an implementation of this recently for AsyncSSH, and I have matched the above in the case where regular keys are used, with the first and third identifiers being rsa-sha2-256/rsa-sha2-512 and the second identifier remaining ssh-rsa when the new-style signatures are used. However, I also wanted to verify the correct identifiers to use in the certificate case.
Right now, I’m using
ssh-rsa-cert-v01%openssh.com@localhost as both the first and second identifier in the certificate case, and only using rsa-sha2-256/rsa-sha2-512 for the third identifier associated with the signature. This seems to work when talking to an OpenSSH server, and in fact OpenSSH doesn’t seem to accept the certificate if the first identifier does not identify that a certificate is being used, even if the second identifier indicates that a certificate was provided as the public key blob.
I know that certificates are OpenSSH-specific, so my apologies in advance if this is the wrong list to ask this question on. I just happened to see this thread in the mailing list archive, and though it would be good to get confirmation from the group.