How to edit known_hosts when several hosts share the same IP and DNS name?

Question

I regularly ssh into a computer which is a dual-boot OS X / Linux computer. The two OS instance do not share the same host key, so they can be seen as two host sharing the same IP and DNS. Let's say the IP is 192.168.0.9, and the names are hostname and hostname.domainname

As far as I understood, the solution to be able to connect to the two host is to add them both to the ~/.ssh/know_hosts file. However, it is easier said than done, because the file is hashed, and has probably several entries per host (192.168.0.9, hostname, hostname.domainname). As a consequence, I have the following warning

Warning: the ECDSA host key for 'hostname' differs from the key for the IP address '192.168.0.9'

Is there an easy way to edit the known_hosts file, while keeping the hashes. For example, how can I find the lines corresponding to a given hostame? How can I generate the hashes for some known hosts?

The ideal solution would allow me to connect to seamlessly to this computer with ssh, no matter whether I call it 192.168.0.9, hostname or hostname.domainname, nor if it uses its Linux hostkey or its OSX hostkey. However, I still want to receive a warning if there is a real man-in-the middle attack, i.e. if another key than these two is used.

Answer 1

The most straightforward solution here is just to use the same host keys for Linux and OS X. That is, pick one set of /etc/ssh/ssh_host_*_key* files and copy them over to the other OS. Then the same host key will presented to an SSH client regardless of which OS you've booted into, and the SSH client will be none the wiser.

Answer 2

As @Izzy suggested in an above comment, ssh tells you the offending line, and by removing that line, (saving it elsewhere), accepting the new key, and then copying the removed line back, you wind up with two keys for the same host, and ssh will accept either.

(You can also use ssh-keygen -H -F <hostname> to find lines in your known_hosts file that match that hostname. Running this after copying the removed line back should list two entries.)

If anyone knows how to get PuTTY to do the same thing, I'd be very interested to hear about it.

Answer 3

I found this that may help you with what you want to achieve.

Source: https://stackoverflow.com/questions/733753/how-to-handle-ssh-host-key-verification-with-2-different-hosts-on-the-same-but

Create a config file in your .ssh directory as follows:

Host server1
  Hostname x1.example.com
  HostKeyAlias server1
  CheckHostIP no
  Port 22001
  User karl

Host server2
  Hostname x2.example.com
  HostKeyAlias server2
  CheckHostIP no
  Port 22002
  User karl

Explanation Below (from man ssh_config)

CheckHostIP

If this flag is set to "yes", ssh(1) will additionally check the host IP address in the known_hosts file. This allows ssh to detect if a host key changed due to DNS spoofing. If the option is set to "no", the check will not be executed. The default is "yes".

HostKeyAlias

Specifies an alias that should be used instead of the real host name when looking up or saving the host key in the host key database files. This option is useful for tunneling SSH connections or for multiple servers running on a single host.

The Username and Port line avoids you having to give those options on the command line, too, so you can just use:

% ssh server1
% ssh server2

Answer 4

I don't run into that problem when connecting to various VPS boxes sharing the same IP because each has a different SSH port (20022,30022, etc) so they are registered as known hosts with different keys.

Could that be a workaround for you?

Answer 5

The easiest way to solve your issue is to give each host an own/distinct IP address. With 253 addresses available in your (private) net and IPv4, that should be no big deal. Give them fixed IPs (as a DHCP server would identify the machine based on the network cards MAC address, and both would get the same address). I do not see any other solution if you want to keep the security measures (which I wouldn't drop for that little "comfort", either).

Answer 6

Since you want to keep the strict host key checking, I would have them use different known_hosts files. To do this, set up your ~/.ssh/config file (or the /etc/ssh/ssh_config file if you need this to work on multiple local user accounts) like this:

Host myserver.osx
  UserKnownHostsFile ~/.ssh/known_hosts.dual.osx
  # default is ~/.ssh/known_hosts
  Hostname $REALHOSTNAME

Host myserver.linux
  UserKnownHostsFile ~/.ssh/known_hosts.dual.linux
  Hostname $REALHOSTNAME

, replacing $REALHOSTNAME with the actual hostname or IP address, of course. (It doesn't matter which you choose, just as long as you choose something after "Hostname" that would resolve to the IP address, but I'd use the host name in preference to an IP address, just on general principles.)

Then ssh myserver.linux and ssh myserver.osx can thus have different host keys, but you still get the checking. If it's Linux that's up and you type OS X (or vice versa), you'll get the warning (which I believe is the desired affect).

If I had this problem, I'd make sure there was something completely wrong in the main known_hosts file that doesn't match either either one, so that if you type $REALHOSTNAME instead of myserver.osx you get the warning. :-) I'd do that by putting something like

<ip-address-of-github.com> $REALHOSTNAME

in my /etc/hosts, then doing an ssh $REALHOSTNAME and accepting the new key, then taking that entry out.

Answer 7

Another article, which describes several ways for handling your problem:

The second method uses two openSSH parameters: StrictHostKeyCheckin, and UserKnownHostsFile. This method tricks SSH by configuring it to use an empty known_hosts file, and NOT to ask you to confirm the remote host identity key.