The client side in OpenSSH 5.7 through 8.6 has an Observable Discrepancy leading to an information leak in the algorithm negotiation. This allows man-in-the-middle attackers to target initial connection attempts (where no host key for the server has been cached by the client). https://docs.ssh-mitm.at/CVE-2020-14145.html This tool is able to exploit this vulnerability. At the moment, it only checks, if a client is vulnerable, but implementing a full exploit is not hard. Dropbear was not affected by such a vulnerability, because they are allwys sending the default algorithm list. PuTTy has integrated an option to disable/enable preffered host key algorithm order. Mitigation: Clients should always preffere the strongest ciphers per default. By using HostKeyAlgorithms in your configuration file, you need to maintain the list and add new algorithms in the right order. This is error prone and most users do not have enough knowledge about pros and cons of those algorithms.
First, we consider the automatic ordering of host key algorithms an important feature for security. It provides continuity of trust by clients across changes in default algorithm preference in ssh and servers offering hostkeys of different types. Disabling this feature wholesale would IMO result in a net *loss* of security as it would force more connections that already have learned a hostkey to accept a new one of a different algorithm, thereby needlessly exposing them to MITM risk. That being said, commit b3855ff (shipped in openssh-8.4) adjusted the ordering to always use the default if the client has learned a hostkey matching the best-preference algorithm. openssh-8.5 enabled UpdateHostkeys by default (with some restrictions) so most users will automatically learn a best-preference hostkey if one is available at the server. Between these, most users should end up using the default algorithm list. Speaking for myself - I plan to relax the restrictions around UpdateHostkeys' activation, but do not plan to take other action around this "vulnerability". In particular, I do not intend to offer an option to force the use of the default cipher list. IMO too many users would flip it thinking it solved a security problem when the situation is actually far more subtle and the reverse is likely the case.
Thanks for the answer. Now I understand the problem better. Mitigation might be possible, but with the risk of a changing fingerprint due to different preferred algorithms. For most users, this might be more error prone and it's more likely that the users accepts a wrong fingerprint. So the only real mitigation is setting up a CA and using certificates, or is this a wrong assumption? The documentation is updated with your answer and the recommendation how to mitigate this vulnerability was changed. Sorry, that I have escalated this vulnerability.
closing bugs resolved before openssh-8.9