The leak allows an attacker to distinguish first connections that are made without a cached host key, allowing them to target those connections only and reduce their risk of detection.

OpenSSH seems affected, too, but have decided to not fix this. As far as I understand the paper, any fix may have undesirable side effects.

The linked paper here https://www.fzi.de/en/news/news/detail-en/artikel/fsa-2020-2... goes into detail. The PDF is in English, despite the German URL.

Yes,

That is exactly the reported issue here. PuTTY 0.68 through 0.73 allows the remote attacker to accurately determine whether or not the client has cached the host key. It looks like this works because PuTTY sends a different algorithm list depending on whether or not the key has been cached.

If the MiTM attacker sees the 'default algorithm list' it can be assumed that this is the first connection attempt and the attacker can substitute the server key with a compromised key.

Ah, that's cool. I pushed AWS to give better ways of getting the host key for new EC2 instances a few years back. The whole start an EC2 instance, SSH in and blinkly trust the host key on first use thing seemed terrible!

EC2 docs now include that detail, although its labeled as optional.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connecti...