|
What type of “advertising SHA-2” do you mean? If the server advertises
rsa-sha2-256 or -512 for server authentication, then it also needs to have an
RSA host key. But the server might not have an RSA host key, it might only have
an ECDSA or Curve25519 host key. However, the server still wants to permit a
client to configure an RSA key for user authentication, and to use SHA-2
signatures for this.
In this situation, the server cannot advertise an rsa-sha2-XXX algorithm
for host authentication. The mechanism for the server to announce support for
SHA-2 signatures in client authentication is using the EXT_INFO message,
specifically the “server-sig-algs” extension described here:
If the server sends an EXT_INFO message with the “server-sig-algs”
extension indicating support for rsa-sha2-256 or rsa-sha2-512, then the client
can assume the server will accept an RSA SHA-2 signature during user
authentication. However, such a signature still has to be correctly encoded
(with the algorithm names as discussed in this thread).
From: Peter Gutmann
Sent: Wednesday, August 3, 2016 04:49
Subject: RE: rsa-sha2-256/512: handling of incorrect signature
encoding denis
bider (Bitvise) <ietf-ssh3%denisbider.com@localhost> writes: >I did set up a test server for the new rsa-sha2-XXX signature types; I posted >connection information here, and included instructions to test both server and >client authentication. I was under the impression that you might have used it, >but I’m not sure if you did. I did, but not for pubkey auth, for lack of a key to auth with. Is it worth stating, in the draft, that if you use sha256 everywhere else then you should also use it for pubkey auth? I can't see any reason why you'd want to use SHA-1 for that when you're using SHA-2 for everything else. Then you could also use the server's advertising SHA-2 to indicate that it'll take a SHA-2 sig for auth. Peter. |