Networking / Beginners

Multiple SSH Host Keys Past NAT

You tried the second method in the previous section 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.

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.

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.

[Previous] [Contents] [Next]

In this tutorial:

  1. Building a Linux Firewall
  2. Iptables and NAT, SNAT, and DNAT
  3. iptables
  4. Assembling a Linux Firewall Box
  5. Configuring Network Interface Cards on Debian
  6. Configuring Network Interface Cards on Fedora
  7. Identifying Which NIC Is Which
  8. Building an Internet-Connection Sharing Firewall on a Dynamic WAN IP Address
  9. Building an Internet-Connection Sharing Firewall on a Static WAN IP Address
  10. Displaying the Status of Your Firewall
  11. Turning an iptables Firewall Off
  12. Starting iptables at Boot, and Manually Bringing Your Firewall Up and Down
  13. Testing Your Firewall
  14. Configuring the Firewall for Remote SSH Administration
  15. Allowing Remote SSH Through a NAT Firewall
  16. Multiple SSH Host Keys Past NAT
  17. Running Public Services on Private IP Addresses
  18. Setting Up a Single-Host Firewall
  19. Setting Up a Server Firewall
  20. Configuring iptables Logging
  21. Writing Egress Rules