Like a lot of people, I ditched my desktop in 2007 and moved to a laptop as my main computer. I take my Macbook Pro to work everyday and it’s also my personal computer at home.
To make life simpler I have an almost identical network set up at home as we do in the office, using the same DHCP range and gateway address (our dev server is also our gateway in the office). So the development server I SSH into at work has the same IP as my home linux box. At work we have internal DNS set up, I’m a little more lazy at home and just refer to my linux box by IP.
A problem arises doing this though; since I connected to the office development server with SSH first, it got first place in my known_hosts file, consequently when I connect to my home linux server (with the same internal IP address) I’m presented with a warning ‘REMOTE HOST IDENTIFICATION HAS CHANGED!’ and I that I could be subject to a ‘man in the middle attack’.
Oh noes!
Of course this isn’t really the case, my linux server just has a different RSA key fingerprint to the office dev machine. There’s two ways we can surpress this…
First Method – disable strict key checking & tell ssh to shut up
When you SSH to a machine for the first time, you’re prompted to save the machine’s fingerprint to your known_hosts file. Your SSH client will save the hostname (if you used one) and the IP address it resolved to:
<hostname>,<ip> ssh-rsa <public key>
I only recommend this for machines on your LAN / inside your DMZ, and not across the public internet.
SSH always resolves hostnames to an IP and complains if two keys for the same IP address exist in your known_hosts. To surpress this you can use the following arguments:
$ ssh -o "StrictHostKeyChecking=no" -q hostname
That’s quite a handful to type, you can alias this command in bash to save your fingers some work.
$ alias sshq="ssh -o 'StrictHostKeyChecking=no' -q" $ sshq hostname
Method Two – temporarily ignore your known_hosts
Using the -o switch we can redefine the location of our known hosts file to /dev/null by overriding UserKnownHostsFile. Observe:
$ ssh -o "UserKnownHostsFile /dev/null" [email protected] The authenticity of host '192.168.0.1' can't be established. RSA key fingerprint is 35:f8:d4:46:0e:...:9f. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.0.1' (RSA) to the list of known hosts. Linux hostname 2.6.18-6-k7 #1 SMP Mon Oct 13 16:52:47 UTC 2008 i686
While SSH has said it’s saved your server IP to known hosts, it really hasn’t as it’s writing to /dev/null.
Hopefully these two methods prove more convenient than swapping known_hosts files.
comments
To keep the securtity, but have this work, you can leverage `~/.ssh/config`, by telling it to use two different `known_hosts` files depending upon where you’re connecting.
To connect, you will use `ssh home` to connect to the home server and `ssh work` to connect to the work server.
First, in `~/.ssh/known_hosts_home`, put the `, ssh-rsa ` for your home server, and in `~/.ssh/known_hosts_work`, put the `, ssh-rsa ` for your work server (or you can leave both files empty, and ssh will write this information the first time, but you should ensure your’re not victim of a man-in-the-middle attack at that moment).
Then, in `~/.ssh/config`, add the following lines:
Host home
# This is optional:
User yourusername
# This is optional, especially if the hostname is resolved by the DNS or by /etc/hosts:
Hostname 192.168.0.1
# This is optional, useful only if you use public/private key authentification (you can generate the keys using ssh-keygen):
IdentityFile ~/.ssh/id_rsa_home
UserKnownHostsFile ~/.ssh/known_hosts_home
Host work
# This is optional:
User yourusername
# This is optional, especially if the hostname is resolved by the DNS or by /etc/hosts:
Hostname 192.168.0.1
# This is optional, useful only if you use public/private key authentification (you can generate the keys using ssh-keygen):
IdentityFile ~/.ssh/id_rsa_work
UserKnownHostsFile ~/.ssh/known_hosts_work