3.13. Getting Multiple SSH Host Keys Past NAT

Problem

You tried the second method in the previous recipe and it worked like a charm. Until you tried to SSH into a second LAN host, that is. Because the remote SSH client sees only a single IP address for your entire network, it freaks out when you try to log in to a second host, displays this scary warning, and refuses to let you log in:

	@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
	WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
	@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
	IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Every LAN host is going to have a different host key with the same IP address because all outgoing traffic is source NAT-ed to the firewall address, so SSH is going to think you're trying to log in to a single PC that keeps changing the host key. What are you going to do? Deleting the host key every single time doesn't seem very practical, and you don't want to turn off StrictHostKeyChecking.

Solution

Use OpenSSH's elegant mechanism for managing multiple host keys that are bound to the same IP address.

Create a ~/.ssh.config file on your remote PC. This example manages the host keys for host1 and host2. The Host entry can be anything you like; some sort of descriptive name is good. HostName is either the fully qualified domain name or IP address of the firewall. Port is the port number from the corresponding iptables rule, and UserKnownHostsFile is the name of file that you want to store the host key in:

	Host host1
	HostName firewall.domainname.net
	Port 10001
	UserKnownHostsFile ~/.ssh/host1

	Host host2
	HostName firewall.domainname.net
	Port 10002
	UserKnownHostsFile ~/.ssh/host2

Log in from the remote host like this:

	$ ssh host1

At the first login, it will ask you the usual:

	The authenticity of host 'firewall.domainname.com (1.2.3.4)' can't be
	established.
	RSA key fingerprint is 00:01:02:03:04:05:00:01:02:03:04:05
	Are you sure you want to continue connecting (yes/no)?

Type "yes," and it will create ~/.ssh/host1 and copy the host key to it. Do the same for all LAN hosts you want SSH access to, and both you and SSH will be happy and will not generate scary warnings.

Discussion

This works for static and dynamic WAN IP addresses. Dynamic WAN IPs will require a bit of extra work if you're using the IP address as the HostName because, obviously, when the address changes, you'll need to change your remote ~/.ssh.config HostName setting. One way to avoid this is to register a domain name and use Dyndns. org's dynamic DNS service, which will allow you to use your FQDN instead of the IP address.

Even better, get a static routable public WAN IP address.

Some folks like to disable StrictHostKeyChecking in ~/ssh.conf, which means disabling an important safety feature.

See Also