Description Thomas Wolf 2021-07-03 15:51:58 EDT

If a user already has a host key for a particular host in ~/.ssh/known_hosts, host key signature algorithms in the KEX proposal are re-ordered to put those for known keys at the front. This helps avoid extra prompts to the user if a host has an additional new host key but preferring to stick with the already known key.

Traditionally, key types and signature algorithms corresponded one-to-one. But that has changed with the introduction of the "rsa-sha2-512" and "rsa-sha2-256" signature algorithms: for RSA keys, there are now three possible signature algorithms.

JGit still simply puts the key type at the front, which for an RSA key is "ssh-rsa", and which is also the deprecated SHA1withRSA signature algorithm.

So JGit proposes "ssh-rsa,ecdsa-sha2-nistp256,...,rsa-sha2-512,rsa-sha2-256,..." if an RSA host key is already known. While technically correct, this means it prefers the deprecated and weak SHA1withRSA signature, even if both client and server would support the newer and stronger SHA2 algorithms.

There is also at least one Github enterprise instance that gets confused by this proposal: although the KEX negotiation result is "ssh-rsa", it then sends a KEX reply using "rsa-sha2-512".[1] That then fails on the client side.

JGit should put all three signature algorithms at the front and propose "rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,...".

[1] https://www.eclipse.org/forums/index.php/t/1108282/