Load balance SSH without “Potential Security Breach” or “Someone Is Doing Something Nasty”
You setup a couple servers with SSH and load balance these. Then, Linux users start reporting they are seeing “It is possible that someone is doing something nasty!” Windows users say that PuTTY is complaining “Warning – potential security breach!” Why?
SSH uses a RSA private/public key pair. The public key is saved on the client as the SSH server fingerprint. Linux users can find these keys under ~/.ssh/known_hosts and ~/.ssh/known_hosts2. Windows users can find the keys in the registry under [HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHo stKeys]. The errors occur when two (or more) SSH servers use the same FQDN but use different private keys.
This is the same thing we see when we load balance Web servers. The workaround there is to export the private/public certificate from one computer, and apply it to all computers in the load balanced set. The clients then receive the same certificate regardless of which computer they connect their Web browser to.
The same workaround applies to load balanced SSH servers. Take the certificate from one, and apply it to all other SSH servers in the set.The files are/etc/ssh/ssh_host_rsa_key (private) and /etc/ssh/ssh_host_rsa_key.pub (public). You may also want to copy /etc/ssh/ssh_host_dsa_key and /etc/ssh/ssh_host_dsa_key.pub if you are supporting DSA encrypted sessions.
A word of caution in regards to the security and validity of the private keys. We had the same discussion with Web servers. The idea behind private/public encryption is that one (and only one) entity has the private keys. This guarantees to the end-user the identification of the remote end-point. Copying the keys reduces that guarantee. Given it is one entity (your organization) that controls the keys, and given you are applying them only to a single DNS hostname backed by a single load balanced set, you should rest easy. Just take care not to copy the SSH keys to anything other than these servers.
OpenSSH client (4.1) error message:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Please contact your system administrator.
Add correct host key in /home/me/.ssh/known_hosts to get rid of this message.
Offending key in /home/me/.ssh/known_hosts:xx
RSA host key for hostname has changed and you have requested strict checking.
Host key verification failed.
PuTTY (0.54) error message:
WARNING – POTENTIAL SECURITY BREACH!
The server’s host key does not match the one PuTTY has
cached in the registry. This means that either the
server administrator has changed the host key, or you
have actually connected to another computer pretending
to be the server.
The new key fingerprint is:
ssh-rsa 1024 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
If you were expecting this change and trust the new key,
hit Yes to update PuTTY’s cache and continue connecting.
If you want to carry on connecting but without updating
the cache, hit No.
If you want to abandon the connection completely, hit
Cancel. Hitting Cancel is the ONLY guaranteed safe
choice.