Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This question already has an answer here:

How do I skip the "known_host" question the first time I connect to a machine via SSH with public/private keys?

share|improve this question

migrated from Aug 7 '09 at 13:51

This question came from our site for professional and enthusiast programmers.

marked as duplicate by sleske, Tog, Mokubai, Simon Sheehan, mpy Oct 15 '13 at 15:14

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

All the other current answers are missing the UserKnownHostsFile=/dev/null

If you just want to do it once you can use:

ssh -o StrictHostKeychecking=no hostname

If you want to do it repeatedly you should add something like the following to your ~/.ssh/config

Host 192.168.0.*
    StrictHostKeyChecking no

To configure this on OpenSSH for Windows simply replace /dev/null with NUL.

Good explanation from:

share|improve this answer
I've been hunting for away to filter out a subnet for months (not actively), this is exactly what I've been wanting. We have a small development network with dhcp and our devices are always getting new IP address, this making connecting to them MUCH easier. Thanks! – Adam Lewis Sep 1 '15 at 15:24

Turn StrictHostKeyChecking off via ssh_config or command line options.

share|improve this answer
/etc/ssh/ssh_config or ~/.ssh/config --- or whatever the equivalent is on windows if that's your client platform – Doug Harris Oct 14 '09 at 15:58

I think everyone missed the point. Sometimes you need to use ssh in a context where you know the host key will alwyays be changing such as installing new servers via serial console & ssh instead of standing in the cold server room at a crash cart. You re-use the same dhcp lan ip's all the time for different servers and different reboots/reloads of a given piece of hardware. The remote machine is utterly temporary and dynamically generated since it just booted up a live cd or an install media via pxe. You're not using ssh because it's "secure". You're using ssh because the installers don't offer the option to use telnet.

The answers above are either completely impractical, or don't actually work. I have both in my /etc/ssh/ssh_config on the client machine: CheckHostIP no StrictHostKeyChecking no

Yet it still adds the remote keys (automatically at least) to known_hosts and then refuses to connect to that same ip later when the ip gets re-used or I reinstall the box. I might reboot a given box into the install system or live/rescue system a dozen times in a day or in an hour testing different options or different distributions or versions etc, and every single reboot will generate a new host key since the "host" is all just a transient ramdisk, and every time I have to go manually edit the damned line out of the damned known_hosts file just to ssh back in... On one box I went so far as to link known_hosts to /dev/null so that it always automatically adds the key and never finds it already there mismatched. But I can't very well do THAT on most of my boxes that I would otherwise want to ssh from. What then.. a wrapper script that captures the ip and erases the matching host key automatically just before calling the real ssh binary? Le Suck.

Damned annoying. I wish people (in this case openssh authors) would stop assuming they know what I should and shouldn't do without ever having met me or seen what exactly the job is I need done or in what context I'm doing it.

share|improve this answer
My answer works 100% – Jason Axelson Feb 4 '12 at 0:15
$ ssh -o StrictHostKeychecking=no hostname

This will cause the check to be skipped and the remote host's key to automatically be added on first login. (There's also the option CheckHostIP, but it doesn't seem to actually disable the check for whether a key exists at all).

share|improve this answer
I also like to use UserKnownHostsFile so that the signature isn't remembered on my system. A nice trick: ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeychecking=no hostname – metavida Apr 10 '12 at 21:54

This took me a while to find. The most common usecase I've seen is when you've got ssh tunnels to remote networks. All the solutions here produced warnings which broke my scripts (nagios).

The option I needed was:

NoHostAuthenticationForLocalhost yes

Which, as the name suggests also only applies to localhost.

share|improve this answer

You can get the public key, add it to known_hosts file and then rehash it:

ssh-keyscan -t rsa hostname >> .ssh/known_hosts
ssh-keygen -H
rm .ssh/known_hosts.old
share|improve this answer

You can disable the checking, but of course that is less secure. In an ideal situation what you should do is get someone that already has access to the machine to grab it's public host key and tell ssh to use it. i.e.: take the output of:

cat /etc/ssh/

prepend the hostname of the machine, and add that line to the ~/.ssh/known_hosts file on your machine. You'll end up with something that looks like: ssh-rsa AAAAB3Netc...

Alternately, if you just want to grab the fingerprint of the key, which may be easier to transfer over a limited bandwidth channel (like a phone call), you can have your helper run:

ssh-keygen -lf /etc/ssh/
share|improve this answer

If you just want to temporarily disable host checking, so you can log into a LiveCD system, for instance, rename ~/.ssh/known_hosts to something else, and then change it back when you're done.

share|improve this answer
  1. Add "StrictHostKeyChecking no" to /etc/ssh/ssh_config
  2. cd ~/.ssh
  3. rm known_hosts
  4. ln -s /dev/null known_hosts


share|improve this answer
You do know what kind of attack this question is supposed to prevent, do you? – vonbrand Mar 8 '13 at 18:19