That is true and it is the first place I usually check when I compromise a new server.

This wasn't mentioned in the post but imagine you compromised a server and found an unprotected ssh key. You don't know where it can be used, and the .bash_history has rolled over or has very few ssh commands in it. You see a lot of hosts in the known_hosts file though but it is hashed. That is where this would be helpful, and is why I went down this route.

Let's suggest an alternative scenario - the hosts and ports are encrypted.

Now what can the attackers do? Well, they still have hashes of public keys. The attacker can scan the entire IPv4 Internet with Z-MAP, and record all SSH public keys. With some hashing, the host can be identified. With online services like Censys (https://censys.io/), the attackers don't even have to scan and compute, but can directly obtain the information from a public database...

Also, to make it clear, while I'm saying that the attack is too impractical to make sense, I have full respect to your research project, thanks for analyzing this security issue for the community.

> first place I usually check when I compromise a new server

Probably don't want to admit publicly that you compromise servers, though I assume you mean with consent. :-)

Yes, with concent of course (Red Teaming).

Or run nmap, or look at your own IP address and just guess at it, or look at your /var/log/messages and ssh logs, all of which are likely just as effective and way less time-consuming than cracking hashed host information.

This isn't really a vulnerability. It's a curiosity. If you're on the sever (or NFS), and have access to this information already, then you're already in pretty damn good shape. This just allows you to be more thorough.