I'm trying to upgrade my ssh server from 2048-bit RSA keys to larger keys, as recommendations are to phase out 2048-bit keys soon.
I generated a new key, then added it to the sshd config, like this:
HostKey /etc/ssh/ssh_host_rsa_key (old 2k-bit key first) HostKey /etc/ssh/ssh_host_rsa4096_key (new larger key 2nd)
After restarting sshd
, I ssh'd to the host, I don't get the identification changed warning, however the new also isn't cached in ~/.ssh/known_hosts
. If I put the lines in the opposite order, I get the identification changed warning. Similarly, when I add an ed25519 key, no matter what order I put it in, the client doesn't add the new key to the known hosts file.
This seems to make SSH host key rollover impossible—difficult to believe that's really the case, though, considering security routinely requires upgrading keys.
I know you can just swap the key, then every client needs to run ssh-keygen -R
to remove the old key, then manually verify and accept the new key—but that's a real pain, especially if you have a lot of clients connecting or don't administer all the clients. Not to mention, if you don't administer the clients, there is a very good chance they won't actually check the host key and instead just hit Y—so the attempt to improve security will likely actually open you to man-in-the-middle attacks instead.
Is there some way to make SSH host key upgrades work? That is, clients should learn the new more secure key (and also hopefully un-learn the obsolete key). And without giving the host key changed man-in-the-middle warning.