Disable SSH Known Host Checking
We’ve all ran into this annoying message when using ssh to connect to more than one computer behind the same IP address.
Offending key in /root/.ssh/known_hosts
And we all know that deleting the offending line in that file will solve our problems, but doing it every time is such a hassle, and if you need to do this on a constant basis, you really can’t be doing this every time. Well, a quick change to your SSH’s configuration file will do the trick!
Open the file /etc/ssh/ssh_config in your favorite text editor, and add the following two lines below Host * in the configuration file.
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
This will disable strict host checking, and automatically write the known hosts to a black hole. You will never be disturbed by that prompt again!
NOTE: If your network security isn’t extrapolated from this process somehow, you probably don’t want to disable this check.
3 Responses to “Disable SSH Known Host Checking”
Leave a Reply




bikerbreath on March 25th, 2011
Using openSSH, this also works — but only if you have root access to the machines you are ssh-ing into:
Copy one set of host ssh key files to all ssh servers behind the same ip address. These keys are in several files named similarly to
/etc/ssh/ssh_host_dsa_key
Some of those key files (the private keys) are only root-readable. Keep them that way.
With the same host keys on all ssh servers, there will be no complaint about “host key has changed” from your ssh client, and you can keep strict host key checking enabled.
Of course, I have no idea about cryptography, so I wouldn’t know if the act of sharing your host keys across many disparate servers is a good idea. So far, so good, though.
Can someone comment on security issues, or other issues that could result from sharing of these host keys?
– Kevin
Cody on March 25th, 2011
You shouldn’t disable this globally but only client side as it opens you up for MITM attacks. Part of the protocol and usefulness of storing the fingerprints of each host is you can ensure that future connections are to the same host – encryption & authentication
.
If you have to do this (behind NAT?) I’d suggest using a local SSH config instead (~/.ssh/config) and only disable the checks for known for known hosts.
@BikerBreath
That’s not really a good idea. If one set of keys was compromised then every machine would be affected.
It’s *good* that SSH asks you by default if you’re connecting to a new host. This allow you to establish the trust in the initial connection – once you do that you can ensure all subsequent connections to that host is 100% that host and 100% encrypted with no snooping. If the fingerprints don’t match from your known one SSH will warn you possibly preventing you from being victim of a MITM attack.
bikerbreath on April 10th, 2011
Thanks, Cody, good point… I am keeping all my eggs in one basket by using one set of keys for ssh.
Yes, the underlying problem is NAT. I suppose the real solution is to wait for IPv6 to hit the streets here.