258

I get the following prompt everytime I try to connect a server using SSH. I type "yes", but is there a way to aovid this?

The authenticity of host '111.222.333.444 (111.222.333.444)' can't be established.
RSA key fingerprint is f3:cf:58:ae:71:0b:c8:04:6f:34:a3:b2:e4:1e:0c:8b.
Are you sure you want to continue connecting (yes/no)? 
quack quixote
  • 43,504
shantanuo
  • 2,883

10 Answers10

344

Use the -o option,

ssh -o "StrictHostKeyChecking no" user@host
Oliver Salzburg
  • 89,072
  • 65
  • 269
  • 311
thegeek
  • 4,098
  • 1
  • 19
  • 7
168

Add the following lines to the beginning of /etc/ssh/ssh_config...

Host 192.168.0.*
   StrictHostKeyChecking no
   UserKnownHostsFile=/dev/null

Options:

  • The Host subnet can be * to allow unrestricted access to all IPs.
  • Edit /etc/ssh/ssh_config for global configuration or ~/.ssh/config for user-specific configuration.

See http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html

JimFred
  • 1,840
28

You should only get this the first time you connect to a new host. After you respond yes the host gets stored in ~/.ssh/known_hosts and you won't get prompted the next time you connect.

Note that if ~/.ssh/known_hosts can not be written for any reason (e.g. permissions problem) then you will get prompted every time you connect.

Paul R
  • 5,708
11

The best way (because it does not sacrifice security) is to connect once to all computers from one client (you'll be prompted every time, always answer yes). As pointed out in the other answer, the keys will then be stored in ~/.ssh/known_hosts. Then copy this file to every client computer you might later want to connect from (possibly for each user account you use). Then all these accounts will "know" the computers, hence no prompt.

The advantage over just disabling the prompt is that SSH can actually check if there is a MITM attack.

sleske
  • 23,525
6

A safer and better way to do is add

Host *
        StrictHostKeyChecking accept-new

to ~/.ssh/config file.
The newer option accept-new in open-ssh client will accept new keys but will reject if the existing keys don't match. You can also use no however accept-new is a better way of doing it.

2

I had faced a similar issue where despite using the above mentioned verified solution, my ssh was not working and it was because the known_hosts file was missing from ~/.ssh/ directory and the File System was read only. SO during run time also I was unable to create the ~/.ssh/known_hosts file.

If you face the similar issue then see if you can write the known_hosts file in the /tmp location. This is mostly write enabled even in a read-only file system.

Later in the ssh command you can specify the ssh to read the known_hosts file from /tmp location.

ssh -o UserKnownHostsFile=/tmp/known_hosts -o StrictHostKeyChecking=no user_name@destination_server_ip
2

If you want to disable the confirmation, rather than the authentication, you can use the option: "-o CheckHostIP=no"

ssh -i sergeys_rsa_key.pem -o CheckHostIP=no brin@8.8.8.8
R J
  • 161
1

If your goal is to connect to a predetermined host in a clean enviroment (ex. a ci pipeline) you can pregenerate the known_hosts file:

First in your enviroment:

$ ssh -oUserKnownHostsFile=known_hosts example.com
The authenticity of host 'example.com (2606:2800:21f:cb07:6820:80da:af6b:8b2c)' can't be established.
ED25519 key fingerprint is SHA256:/IJSyNxVg5lnxYua11Wlm2G2fBMifdrkvT94o4vzlPc=.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'example.com' (ED25519) to the list of known hosts.

After confirming, you can then use that known_hosts file to verify the authenticity of the host without user interaction.

$ ssh -oUserKnownHostsFile=known_hosts example.com
-1

This is probably because your ssh key server changed, since server ip or domain is the same but ssh key mismatch.

You must remove the stored key in /home/$user/.ssh/known_hosts to avoid this message.

I fixed it removing all keys in that file, so new token is created for this domain name.

-3

Check the permissions on your ~/.ssh/known_hosts file. Mine were incorrect when I got this problem. I fixed it with:

chmod 0600 ~/.ssh/known_hosts
AMc
  • 95