Order proposed host key algorithms by known hosts #642
Comments
WorkDayHeyHey
pushed a commit
to WorkDayHeyHey/sshj
that referenced
this issue
Sep 22, 2021
(hierynomus#642, hierynomus#635... 10? issues) Try to find the Algorithm that was used when a known_host entry was created and make that the first choice for the current connection attempt. If the current connection algorithm matches the algorithm used when the known_host entry was created we can get a fair verification.
hierynomus
added a commit
that referenced
this issue
Sep 23, 2021
* Prefer known algorithm for known host (#642, #635... 10? issues) Try to find the Algorithm that was used when a known_host entry was created and make that the first choice for the current connection attempt. If the current connection algorithm matches the algorithm used when the known_host entry was created we can get a fair verification. * Add support for multiple matching hostkeys, in configuration order Co-authored-by: Bernie Day <[email protected]> Co-authored-by: Jeroen van Erp <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Consider this scenario. We are connecting to a server with an RSA host key, and we store this key in our known hosts thing. The server then adds another key, say, Ed25519. Since sshj prefers Ed25519 over RSA, it will choose to verify using
ssh-ed25519, which will obviously fail and will probably lead to a huge warning to boot.OpenSSH reorders host keys algorithms by host key entries, putting the ones that can be actually used for verification at the front. It would be nice if sshj did the same.
While you can specify algorithms via configuration, it means that one have to create a new configuration for each server. Also, I don't think you can easily get available key types from
OpenSSHKnownHosts.I would expect something along
ssh.setAvailableHostKeyTypes(hostKeys.getAvailableHostKeyTypes(host, port))(Note that for this purpose it might be wise to consider ECDSA keys with different curves as different key types, which sshj seems to be doing anyway)
The text was updated successfully, but these errors were encountered: