Server Fault is a question and answer site for system and network administrators. 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

Here's my situation: I'm setting up a test harness that will, from a central client, launch a number of virtual machine instances and then execute commands on them via ssh. The virtual machines will have previously unused hostnames and IP addresses, so they won't be in the ~/.ssh/known_hosts file on the central client.

The problem I'm having is that the first ssh command run against a new virtual instance always comes up with an interactive prompt:

The authenticity of host '[hostname] ([IP address])' can't be established.
RSA key fingerprint is [key fingerprint].
Are you sure you want to continue connecting (yes/no)?

Is there a way that I can bypass this and get the new host to be already known to the client machine, maybe by using a public key that's already baked into the virtual machine image ? I'd really like to avoid having to use Expect or whatever to answer the interactive prompt if I can.

share|improve this question
up vote 72 down vote accepted

Set the StrictHostKeyChecking option to no, either in the config file or via -o :

ssh -o StrictHostKeyChecking=no

share|improve this answer
ssh -o StrictHostKeyChecking=no – deleted Apr 16 '10 at 5:01
Thanks, Ignacio and cd. – gareth_bowles Apr 16 '10 at 17:20
This leaves you open to man in the middle attacks, probably not a good idea. – JasperWallace Sep 23 '13 at 7:23
@JasperWallace, while this is usually good advice, the specific use case (deploying test VMs and sending commands to them) should be safe enough. – Massimo Oct 21 '14 at 17:33
This gives a Warning: Permanently added 'hostname,' (RSA) to the list of known hosts. To avoid the warning, and to avoid the entry being added to any known_hosts file, I do: ssh -o StrictHostKeyChecking=no -o LogLevel=ERROR -o UserKnownHostsFile=/dev/null – Peter V. Mørch May 21 '15 at 9:19

IMO, the best way to do this is the following:

ssh-keygen -R [hostname]
ssh-keygen -R [ip_address]
ssh-keygen -R [hostname],[ip_address]
ssh-keyscan -H [hostname],[ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [hostname] >> ~/.ssh/known_hosts

That will make sure there are no duplicate entries, that you are covered for both the hostname and IP address, and will also hash the output, an extra security measure.

share|improve this answer
Why do you need all 3 ssh-keyscan's? Can't you get by with just the first one since it works for both hostname and ip? – Robert May 24 '13 at 22:00
Can you be sure that the machine replying to the ssh-keyscan request is really the one you want to talk to? If not you've opened yourself to a man in the middle attack. – JasperWallace Sep 23 '13 at 7:24
@JasperWallace Yes, for that you need at least the fingerprint or even better the public key, in which case you can add it directly to known_hosts, turning this question moot. If you only have the fingerprint, you will have to write an extra step which verifies the downloaded public key with your fingerprint... – ufotds Apr 28 '14 at 21:57
Calls to ssh-keyscan were failing for me because my target host doesn't support the default version 1 key type. Adding -t rsa,dsa to the command fixed this. – phasetwenty Aug 6 '14 at 18:11
This is probably a bad idea. You are opening yourself to a man-in-the-middle attack by updating these keys. To avoid duplicate entries, check the return status of ssh-keygen -F [address] instead.… – retrohacker Sep 29 '15 at 3:04

As mentioned, using key-scan would be the right & unobtrusive way to do it.

ssh-keyscan -t rsa,dsa HOST 2>&1 | sort -u - ~/.ssh/known_hosts > ~/.ssh/tmp_hosts
mv ~/.ssh/tmp_hosts ~/.ssh/known_hosts

The above will do the trick to add a host, ONLY if it has not yet been added. It is also not concurrency safe; you must not execute the snippet on the same origin machine more than once at the same time, as the tmp_hosts file can get clobbered, ultimately leading to the known_hosts file becoming bloated...

share|improve this answer
Is there a way to check whether the key is in known_hosts before ssh-keyscan? The reason is that it requires some time and additional network connection. – utapyngo May 23 '14 at 7:49
The original poster's version of this file had cat ~/.ssh/tmp_hosts > ~/.ssh/known_hosts, but a subsequent edit changed it to >>. Using >> is an error. It defeats the purpose of the uniqueness in the first line, and causes it to dump new entries into known_hosts every time it runs. (Just posted an edit to change it back.) – paulmelnikow Jul 27 '15 at 17:46
This is subject to the same MITM attacks as the others. – Mnebuerquo Jun 15 at 17:18

For the lazy ones:

ssh-keyscan <host> >> ~/.ssh/known_hosts
share|improve this answer
+1 for being guilty as charged. Thanks. – SaxDaddy Oct 28 '14 at 17:59
"ssh-keyscan -H <host> >> ~/.ssh/known_hosts" produces an entry more like what ssh does with user interaction. (The -H hashes the name of the remote host.) – Sarah Messer Sep 4 '15 at 20:19
Vulnerable to MITM attacks. You're not checking the key fingerprint. – Mnebuerquo Jun 15 at 17:20

You could use ssh-keyscan command to grab the public key and append that to your known_hosts file.

share|improve this answer
Make sure you check the fingerprint to ensure it is the correct key. Otherwise you open yourself up to MITM attacks. – Mnebuerquo Jun 15 at 17:20

This is how you can incorporate ssh-keyscan into your play:

# ansible playbook that adds ssh fingerprints to known_hosts
- hosts: all
  connection: local
  gather_facts: no
  - command: /usr/bin/ssh-keyscan -T 10 {{ ansible_host }}
    register: keyscan
  - lineinfile: name=~/.ssh/known_hosts create=yes line={{ item }}
    with_items: '{{ keyscan.stdout_lines }}'
share|improve this answer
Are you uploading a known valid known_hosts file, or are you doing ssh-keyscan and dumping the output into known_hosts without verifying fingerprints? – Mnebuerquo Jun 15 at 17:22
This is simply dumps output of a keyscan, yes. So in effect it's the same as StrictHostKeyChecking=no, just with silent known_hosts updating without fiddling with ssh options. This solution also doesn't work well due to ssh-keyscan returning multiple lines which causes this task always be flagged as 'changed' – Zart Jun 16 at 21:42

I had a similar issue and found that some of the provided answers only got me part way to an automated solution. The following is what I ended up using, hope it helps:

ssh -o "StrictHostKeyChecking no" -o PasswordAuthentication=no 10.x.x.x

It adds the key to known_hosts and doesn't prompt for the password.

share|improve this answer
Thanks man! This do the trick! – Stas Berkov Dec 19 '14 at 13:40
Vulnerable to MITM attacks. You're not checking the fingerprint. – Mnebuerquo Jun 15 at 17:23

Your Answer


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.