251

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)?
Improve this question
3
  • 13
    /dev/null exists for those who think they are immune to man in the middle attacks :)
    – Tim Post
    Commented Mar 29, 2010 at 10:08
  • 1
    Worst part: Type y to save some time, and it complains: Please type 'yes' or 'no': (hmph)
    – ADTC
    Commented Nov 29, 2017 at 18:59
  • similar to askubuntu.com/questions/87449/…
    – MarkHu
    Commented Mar 21, 2019 at 4:45

10 Answers 10

Reset to default
335

Use the -o option,

ssh -o "StrictHostKeyChecking no" user@host
Improve this answer
5
  • 1
    You may want to use an alternate identity file with the flag '-i'
    – MUY Belgium
    Commented Apr 22, 2013 at 10:08
  • 2
    What use would using an alternate identity file be? I mean, if you're connecting to a compromised host, what difference does it make how you authenticate - it's not like the compromised host can steal your key too.
    – Dagelf
    Commented Jun 2, 2015 at 10:16
  • Perfectly valid answer. Just please note that this is insecure, and it opens you up to "man-in-the-middle" attacks.
    – cowlinator
    Commented May 6, 2021 at 22:18
  • 3
    On my computer a related man page (man 5 ssh_config) says that there are more alternatives to no, including accept-new, where ssh "will automatically add new host keys to the user known hosts files, but will not permit connections to hosts with changed host keys." This seems like it would still solve this problem in many cases while being more secure. (There is also yes, which skips the prompt and rejects unknown and changed hosts. Also off is the same as no and ask is the default, which prompts.)
    – David Winiecki
    Commented Sep 29, 2022 at 17:11
  • 1
    According to the man page, StrictHostKeyChecking will "automatically add new host keys to the user known hosts files" when set to no or off, which is worth noting. See JimFred's answer if you just want to connect once without adding anything to the known hosts (may be useful in some cases).
    – Wilderness Ranger
    Commented Jul 24, 2023 at 17:05
161

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

Improve this answer
5
  • 7
    Pity I can only upvote you once. Setting KnownHosts to /dev/null is genius.
    – Max Cameron
    Commented Aug 8, 2014 at 15:15
  • 2
    Your the smartest one.
    – Darth Egregious
    Commented Sep 5, 2014 at 20:08
  • 52
    Ha! Tell my wife.
    – JimFred
    Commented Sep 6, 2014 at 21:16
  • 1
    This should be the answer
    – Miquel
    Commented Nov 18, 2020 at 12:21
  • From experience when mixing space-separated and = separated options in an .ssh/config SSH sometimes seems to choke on the latter. Better to stay consistent.
    – 0xC0000022L
    Commented Sep 12, 2023 at 8:51
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.

Improve this answer
5
  • 12
    The question is is there anyway to avoid the prompt?
    – shantanuo
    Commented Mar 29, 2010 at 10:44
  • I tried adding "CheckHostIP no" to /etc/ssh/ssh_config file. But it does not seem to be working
    – shantanuo
    Commented Mar 29, 2010 at 10:46
  • 2
    sudo chown -R user:user .ssh ; sudo chmod 700 .ssh; sudo chmod -R 600 .ssh/ ; ssh-keygen -R $hostname and reconnect that should take ALL problems out and ONLY ever re-prompt if a ssk_Hostkey is mucked with | changed or you are victim to a MITM.
    – linuxdev2013
    Commented Dec 12, 2015 at 23:28
  • 1
    it says "everytime" so this answer is super appropriate
    – tarikakyol
    Commented Jan 23, 2018 at 14:27
  • 1
    No, it's a terrible answer, because obviously IT KEEPS HAPPENING to the guy, or he wouldn't have asked the question. And to me, too, because I have an IT department that decides they need to "clean out" the known_hosts files on a regular basis.
    – Patrick Maupin
    Commented Sep 3, 2020 at 0:56
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.

Improve this answer
2
  • 1
    Although, if you often ssh via forward connections, you will want to add this to /etc/ssh/ssh_config: Host 127.0.0.1 NoHostAuthenticationForLocalhost yes
    – Dagelf
    Commented Jun 2, 2015 at 10:14
  • 1
    Meanwhile there is a tool named ssh-keyscan to achieve this. You can, btw, also store the keys in /etc/ssh with restrictive permissions to hold the values for those servers that you know won't change and then populate these via a tool like Ansible, Chef or Puppet ...
    – 0xC0000022L
    Commented Sep 12, 2023 at 8:53
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 [email protected]
Improve this answer
1
  • 1
    The OP has already got the same answer and accepted it.
    – Ayan
    Commented Jul 12, 2015 at 4:03
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
Improve this answer
2

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.

Improve this answer
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
Improve this answer
-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.

Improve this answer
1
  • 2
    Key changed produces a much uglier message with a box of atsigns and WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! and IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! in all-caps. The message in the question occurs only if there is not already an entry in known_hosts.
    – dave_thompson_085
    Commented Dec 15, 2015 at 6:15
-2

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
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .