If we need to get a proof of ownership for a RSA key on establishing a connection, the SHA1 algorithm is used by default (see the ssh_rsa_sign function). Not sure that it is the best possible option now. As it is possible to explicitly request the hash, it's worth analyze the client's capabilities and use SHA2 for this purpose.
I'm not sure what you're talking about - there are already extensive negotiation mechanisms that default to SHA2 for user and host authentication.
When we have, say, an ECDSA key confirmed by fingerprint and RSA key to be confirmed, we have EC-based KEX, so the KEX-based prevention of using SHA1 (https://github.com/openssh/openssh-portable/blob/7a7c69d8b4022b1e5c0afb169c416af8ce70f3e8/serverloop.c#L725-L730) will not work and SHA1 will be used for the proof of posession of the RSA key.
The condition `kexsigtype == KEY_RSA` in the above link will work only if the rsa-sha2-* hostkey type was negotiated during key exchange and we are sending a proof of possession of another RSA key. In any other case, for example ECDSA or Ed25519 hostkey is negotiated, the above condition will evaluate always to `false` and RSA with SHA1 will be used regardless the client capabilities. I think the above condition should be rewritten to check not against the negotiated hostkey type, but if the client supports the RSA with SHA2 (regardless of the negotiated key type). But I did not have time to look better into the implementation yet.
Created attachment 3559 [details] Here is the proposed solution
I suggest to increase the priority. The problem occurs when we use OpenSSL in FIPS mode, so signing a SHA1 hash becomes not an option.
Created attachment 3561 [details] tweaked diff IMO it's important to retain the current algorithm selection logic for RSA keys, because otherwise the client will reject them for having the wrong signature algorithm. This patch does this and tweaks a few other things.
Created attachment 3562 [details] client side Similarly, if you want to avoid use of RSA-SHA1 completely then you also need to ensure the client only accepts RSA-SHA2 signatures. This patch to the client does this. It will disregard hostkey proofs if they use ssh-rsa except when it has been explicitly negotiated as the hostkey algorithm. AFAIK this should be fine for backwards compatibility, except for the case when a <openssh-8.9 server is configured with multiple RSA keys. I expect this to be a rare situation.
Thanks! I need to test it, but your code looks great. The problem is, when we are in FIPS mode, we shouldn't use sha1 for signature (but still are allowed to use for the verification).
These have been committed now. Thanks for spotting the bug and for providing a fix. If there are any further problems then please reopen this bug
closing bugs resolved before openssh-8.9