In SSH clients OpenSSH and PuTTY ( in PuTTY and in OpenSSH), leading to a leak of information in the connection negotiation algorithm. The vulnerability allows an attacker capable of intercepting client traffic (for example, when a user connects through a wireless access point controlled by the attacker) to determine the client's initial connection attempt to the host, when the client has not yet cached the host key.
Knowing that the client is trying to connect for the first time and does not yet have a host key on its side, the attacker can broadcast the connection through itself (MITM) and give the client its host key, which the SSH client will consider the key of the target host if it does not verify the key fingerprint . Thus, an attacker can organize a MITM without arousing the user's suspicions and ignore sessions that already have cached host keys on the client side, an attempt to replace which will lead to a warning about changing the host key. The attack is based on the carelessness of users who do not manually check the fingerprint of the host key on the first connection. Those who verify key prints are protected from such attacks.
As a sign to determine the first connection attempt, a change in the order of listing of supported host key algorithms is used. If the first connection occurs, the client sends a list of default algorithms, and if the host key is already in the cache, then the algorithm associated with it is put in first place (algorithms are sorted in order of preference).
The problem appears in OpenSSH releases 5.7 to 8.3 and PuTTY 0.68 to 0.73. Problem in issue by adding an option to disable dynamic listing of host key processing algorithms in favor of listing the algorithms in a constant order.
The OpenSSH project does not plan to change the behavior of the SSH client, because if you do not specify the existing key algorithm in the first place, it will try to use an algorithm that does not match the cached key with an unknown key warning. Those. there is a choice - either information leakage (OpenSSH and PuTTY), or key change warnings (Dropbear SSH) in case the saved key does not match the first algorithm in the default list.
To provide security in OpenSSH, it is proposed to use alternative ways to verify the host key using DNSSEC SSHFP records and host certificates (PKI). You can also disable the adaptive selection of host key algorithms via the HostKeyAlgorithms option and use the UpdateHostKeys option to get additional host keys for the client after authentication.
Source: opennet.ru