Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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.

share|improve this question
    
What is it that you want to do? Edit it for what? –  Rhyuk Jul 5 '12 at 13:56
    
@Rhyuk: Edit it to be able to recognize as valid both the OSX and the linux host key for the IP address, the hostname and hostname.domainname. –  Frédéric Grosshans Jul 5 '12 at 14:52
    
@Rhyuk: I've edited th question. Is it more clear now ? –  Frédéric Grosshans Jul 5 '12 at 15:06
2  
Have you simply considered making both installations have the same key? –  Zoredache Jul 5 '12 at 16:17
    
Yes, but I'd prefer not to. Currently they are even different kinds of key (ssh-rsa and ecdsa-sha2-nistp256)! It probably comes from different default sshd configurations... –  Frédéric Grosshans Jul 5 '12 at 16:44
add comment

5 Answers 5

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.

share|improve this answer
add comment

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

Source: http://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
share|improve this answer
    
I saw this article, but it does not corresponds to my case : the two servers are distinguished by port number in the article, not in my case. Furthermore, I'd like to keep the extra layers of security brought by the salted hashes in known_hosts and CheckHostIP. –  Frédéric Grosshans Jul 5 '12 at 15:53
1  
@FrédéricGrosshans, I check checked. You don't have to have seperate ports, and the HashKnownHosts option works fine with HostKeyAlias. –  Zoredache Jul 5 '12 at 19:47
add comment

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.

share|improve this answer
    
I'd prefer a client version, but I'll try this one if I don't find one. By the way, the OSX (non-standard) localization of the files is /private/etc/ssh_host*, not /etc/ssh/ssh_host*. –  Frédéric Grosshans Jul 5 '12 at 17:03
add comment

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).

share|improve this answer
    
Actually, the IP address is not 192.168.0.xx and is not private. It is a 'real' IPv4 address, given by my university which I'm not free to change. –  Frédéric Grosshans Jul 5 '12 at 16:40
    
If you check with Wikipedia, you will see 192.168.0.0 - 192.168.255.255 (your question specified 192.168.0.9, which falls into this range) belongs to the "Private IPv4 address spaces". So by "private" I didn't refer to you "owning" it, but to the specs of the IETF. In your question you did not indicate you cannot change the IP, sorry -- but with the input given, my answer was fitting. –  Izzy Jul 6 '12 at 9:31
    
Sorry for the badly phrased question. I did not downvote. –  Frédéric Grosshans Jul 6 '12 at 12:18
    
No prob, and tnx for letting me know -- makes the downvote less discouraging. But another idea: I'm not sure where the known_hosts file takes the hostname from, reverse DNS or offered by client. You could try renaming one of your "hosts" so it presents a different hostname. Or to have both host keys added: ssh tells you the "offending line" in your known_hosts file (when #1 is contained ynd you connect with #2). So you then could copy that line to another file, remove it from known_hosts, let #2 connect and add its line, and add the removed line back. Not sure if it works, but you can try. –  Izzy Jul 6 '12 at 12:49
add comment

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.

share|improve this answer
    
This paper is about disallowing key-checking. I want to keep the key checking, and I don't want to disallow it each time hostname is rebooted into Linut or OSX –  Frédéric Grosshans Jul 5 '12 at 15:57
    
Welcome to Super User! Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference. I've included a short part, but it might not be what you intended... –  Tom Wijsman Jul 10 '12 at 1:09
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.