Linux – PuTTY Warning: The server’s host key does not match the one PuTTY has cached in the registry

linuxputtyssh

When using PuTTY connect to a new host, I often get the warning

The server's host key does not match the one PuTTY has cached in the
registry.

after I press

Yes

PuTTY adds the server RSA key into the Windows 10's registry, and I will be able to login the remote server, and the warning won't appear again.

I know the RSA key comes as pairs, both public and private.
What I am trying to understand is which key did the server saved into my local machine, the server's public key I guess.

Also when the PuTTY made the initial SSH connection to the server, how the server decides which key to forward? Assume the server has list of the public keys, is there a generic key for any client trying to make the connections?

And where is this generic key stored on the server? under /root/.ssh/ authorized_keys?

Best Answer

Generally you should be very cautious when you get

WARNING - POTENTIAL SECURITY BREACH!

The server's host key does not match the one PuTTY has cached in the registry.

It's an indication of MITM attack.

See also PuTTY documentation for WARNING - POTENTIAL SECURITY BREACH! (what is the main part of the message, which you somehow omitted in your question).

You never get this message for a new server. Unless, of course, the new server reuses IP address/hostname of some discarded server. In which case, it's ok to ignore the warning.


It is, of course, a public key that is cached by PuTTY. A private key is secret and it must not be accessible to anyone, except for the server administrator. So there's no way SSH client can get it.


The server can indeed have a number of key pairs for different algorithms (one for each algorithm, like RSA, DSA, ECDSA, ED25519). The client and the server will agree on the best algorithm to use (the best out of those supported by both the server and the client).


The key pairs are usually stored in /etc/ssh (on Linux with OpenSSH).


Though wording of your question hints that you may confuse the server/host key pair with the key pair you use to authenticate to the server.

See my article on Understanding SSH key pairs.

Related Question