122

I'm getting the standard 

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is

error message. However, the system (Appworx) that executes the command (sftp I think, not that it matters) is automated and I can't easily accept the new key, even after checking with the third party vendor that it is a valid change. I can add a new shell script that I can execute from the same system (and user), but there doesn't seem to be a command or command-line argument that will tell ssh to accept the key. I can't find anything in the man page or on Google. Surely this is possible?

John O
  • 4,863
  • 8
  • 45
  • 78

9 Answers9

145

The answers here are terrible advice. You should never turn off StrictHostKeyChecking in any real-world system (e.g. it's probably okay if you're just playing on your own local home network – but for anything else don't do it).

Instead use:

ssh-keygen -R hostname

or if not using the default port 22:

ssh-keygen -R '[hostname]:port'

That will force the known_hosts file to be updated to remove the old key for just the one server that has updated its key.

Then when you use:

ssh user@hostname

It will ask you to confirm the fingerprint – as it would for any other "new" (i.e. previously unseen) server.

Chris Stryczynski
  • 30,145
  • 48
  • 175
  • 286
AJ Poulter
  • 1,717
  • 2
  • 10
  • 9
  • 10
    Please all note: This is the only correct answer! Use `StrictHostKeyChecking no` for example on local development Docker containers that change their host key on every update of the image, but don't use it for live servers! Really, you don't want that! – Mark van der Sanden Dec 11 '18 at 14:49
  • 9
    This describes adding the key interactively. As such, it isn't the only answer, because you can provide the *actual* key instead. That's better because you use a known-good copy. It also allows automation. – Peter Westlake Mar 15 '19 at 17:25
  • 7
    You can also use `StrictHostKeyChecking accept-new` to accept new keys but still refuse to connect when the saved key conflicts. – Chris Adams Apr 17 '20 at 21:15
  • I agree most of the time it's a bad idea, but in my case I am using SSH to run a remote script from CI. The deploy key is restricted so the only thing it can do is run that script, and the script doesn't take any arguments. Even if there were a man-in-the-middle attack, there is no information being transmitted that could be corrupted or used to advantage. In this case, I think disabling host key checking is pretty reasonable. Perhaps there is some security implication that I have missed? – Resigned June 2023 Jun 11 '20 at 16:06
  • 1
    @RadonRosborough the MITM will be able to read the instructions and data from the script. And they will be able to test how well the key is restricted. Better to update the known_hosts: `ssh-keyscan $target_host >> ~/.ssh/known_hosts`. Too easy to fix the issue, no reason to not do it. – Jeter-work Oct 14 '20 at 20:35
  • running both those lines isn't, in fact, exactly the same as the accepted one liner though? why is it so terrible advice then? – cregox Jan 14 '21 at 16:12
  • @cregox - disabling `StrictHostKeyChecking` disables the validation that the system really is the one that you're expecting to connect to. It's relatively easy (by messing with DNS for example) to direct someone to an imposter server – which could be used to steal credentials for example. It's essentially the same idea as HTTPS / TLS for a browser – which not only secures the connection, but also validates that the wenserver *really is* your_bank.com, etc. – AJ Poulter Jan 17 '21 at 11:52
  • i read it all over, including your comments reply, and still couldn't get it... but when writing this reply, i got it! even if `StrictHostKeyChecking=no` only happens during the one run, it will not only replace the current host (which is what those 2 command here do) but also it won't do the actual check that's done by the 2nd command here. if that's indeed the case, i couldn't agree more with the hate over the other answers. – cregox Jan 17 '21 at 19:15
  • still, by all means, do check the new `StrictHostKeyChecking=accept-new` on the one newer answer [there](https://stackoverflow.com/a/61946687/274502). – cregox Jan 17 '21 at 19:17
  • Ok but what about specifically for `localhost`? Is there any security concern with using `StrictHostKeyChecking=no` when the host is `localhost`? – nullromo Jan 21 '23 at 00:41
90

While common wisdom is not to disable host key checking, there is a built-in option in SSH itself to do this. It is relatively unknown, since it's new (added in Openssh 6.5).

This is done with -o StrictHostKeyChecking=accept-new.

WARNING: use this only if you absolutely trust the IP\hostname you are going to SSH to:

ssh -o StrictHostKeyChecking=accept-new mynewserver.example.com

Note, StrictHostKeyChecking=no will add the public key to ~/.ssh/known_hosts even if the key was changed. accept-new is only for new hosts. From the man page:

If this flag is set to “accept-new” then ssh will automatically add new host keys to the user known hosts files, but will not permit connections to hosts with changed host keys. If this flag is set to “no” or “off”, ssh will automatically add new host keys to the user known hosts files and allow connections to hosts with changed hostkeys to proceed, subject to some restrictions. If this flag is set to ask (the default), new host keys will be added to the user known host files only after the user has confirmed that is what they really want to do, and ssh will refuse to connect to hosts whose host key has changed. The host keys of known hosts will be verified automatically in all cases.

Why -o StrictHostKeyChecking=no is evil?

When you do not check the host key you might land with an SSH session on a different computer (yes, this is possible with IP Hijacking). A hostile server, which you don't own can be then used to steal a password and all sort of data. Accepting a new unknown key is also pretty dangerous. One should only do it if there is an absolute trust in the network or that the server was not compromised. Personally, I use this flag only when I boot machines in a cloud environment with cloud-init immediately after the machine started.

2072
  • 275
  • 3
  • 6
oz123
  • 27,559
  • 27
  • 125
  • 187
63

Here's how to tell your client to trust the key. A better approach is to give it the key in advance, which I've described in the second paragraph. This is for an OpenSSH client on Unix, so I hope it's relevant to your situation.

You can set the StrictHostKeyChecking parameter. It has options yes, no, and ask. The default is ask. To set it system wide, edit /etc/ssh/ssh_config; to set it just for you, edit ~/.ssh/config; and to set it for a single command, give the option on the command line, e.g.

ssh -o "StrictHostKeyChecking no" hostname

An alternative approach if you have access to the host keys for the remote system is to add them to your known_hosts file in advance, so that SSH knows about them and won't ask the question. If this is possible, it's better from a security point of view. After all, the warning might be right and you really might be subject to a man-in-the-middle attack.

For instance, here's a script that will retrieve the key and add it to your known_hosts file:

ssh -o 'StrictHostKeyChecking no' hostname cat /etc/ssh/ssh_host_dsa_key.pub >>~/.ssh/known_hosts
Peter Westlake
  • 4,894
  • 1
  • 26
  • 35
  • 3
    I'm not trying to suppress the warning. I've already gotten it, I will get more in the future. I want a script that, after I've received the warning, I can run the script and have it answer "yes" without it being interactive. I have no way of typing "yes". I was hoping there was a "connect to this host, answer yes, and disconnect" argument to ssh, or some way of accomplishing the same. – John O Jan 27 '14 at 15:54
  • Your command works, though I'm not sure what it's doing. Thank you. I've also added Batchmode to it, so that it exits when it gets to the password prompt. Much appreciated. – John O Jan 27 '14 at 17:07
  • Auto-answering yes is a security vulnerability. It leaves you open to be phished. Unless you are in a private dev environment. Then this can be very helpful. You should verify the fingerprint + password/username or use an ssh public/private key. – TamusJRoyce Mar 10 '19 at 16:24
  • I'm trying to bypass the check one-time only, as I'm trying to connect to my server is rescue mode (therefore I'm actually connecting to a different OS, with a one-time password for the SSH login). I want to retain the current keys. – Sam Bull Dec 30 '20 at 16:23
  • 15
    terrible idea. check other answers and comments to lean why and better alternatives. tldr: use `StrictHostKeyChecking=accept-new` instead. – cregox Jan 17 '21 at 19:23
  • `StrictHostKeyChecking=accept-new` nicely solved my problem of deploying a new host key on 45 servers in one command when, for obscure reasons, `ssh-keyscan` didn't help. Of course in my case, I will only run it once, and then use standard private key logons. – Moonchild Mar 26 '22 at 16:56
  • 2
    @cregox It's not a terrible idea, you just have terrible reading comprehension. This was years ago for me, but I did not have a way to interactively use the system. I could not go in and manually update the key to the new one. And in my situation, I had verified with the external host (over the phone and email) that this was indeed just an inevitable system issue on their end. I was also able to write a script that could execute as a substitute to me sitting there and using the keyboard to confirm I wanted this. It wasn't automated, I had to invoke the script. No one offered an alternative. – John O Sep 22 '22 at 03:55
  • 1
    Worked with docker – JRichardsz Mar 24 '23 at 04:29
49

Since you are trying to automate this by running a bash script on the host that is doing the ssh-ing, and assuming that:

  • You don't want to ignore host keys because that's an additional security risk.
  • Host keys on the host you're ssh-ing to rarely change, and if they do there's a good, well-known reason such as "the target host got rebuilt"
  • You want to run this script once to add the new key to known_hosts, then leave known_hosts alone.

Try this in your bash script:

# Remove old key
ssh-keygen -R $target_host

# Add the new key
ssh-keyscan $target_host >> ~/.ssh/known_hosts
Eric
  • 95,302
  • 53
  • 242
  • 374
Earl Ruby
  • 1,263
  • 12
  • 14
6

You just have to update the current fingerprint that's being sent from server. Just Type in the following and you'll be good to go :) 

ssh-keygen -f "/home/your_user_name/.ssh/known_hosts" -R "server_ip"
Ali Raza
  • 174
  • 1
  • 2
  • 8
4

Just adding the most 'modern' approach.
Like all other answers - this means you are BLINDLY accepting a key from a host. Use CAUTION!

HOST=hostname; ssh-keygen -R $HOST && ssh-keyscan -Ht ed25519 $HOST >> "$HOME/.ssh/known_hosts"

First remove any entry using -R, and then generate a hashed (-H) known_hosts entry which we append to the end of the file.

As with this answer prefer ed25519.

Lockszmith
  • 2,173
  • 1
  • 29
  • 43
1

Get a list of SSH host IPs (or DNS name) output to a file > ssh_hosts

Run a one-liner to populate the ~/.ssh/known_hosts on the control node (often do this to prepare target nodes for Ansible run)

NOTE: Assume we prefer ed25519 type of host key

# add the target hosts key fingerprints
while read -r line; do ssh-keyscan -t ed25519 $line >> ~/.ssh/known_hosts; done<ssh_hosts

# add the SSH Key('s) public bit to target hosts `authorized_keys` file
while read -r line; do ssh-copy-id -i /path/to/key -f user@$line; done<ssh_hosts
Terry Wang
  • 13,840
  • 3
  • 50
  • 43
0
ssh -o UserKnownHostsFile=/dev/null user@host
Tyler2P
  • 2,324
  • 26
  • 22
  • 31
toto
  • 19
  • 1
  • 2
    [A code-only answer is not high quality](//meta.stackoverflow.com/questions/392712/explaining-entirely-code-based-answers). While this code may be useful, you can improve it by saying why it works, how it works, when it should be used, and what its limitations are. Please [edit] your answer to include explanation and link to relevant documentation. – Stephen Ostermiller Feb 03 '23 at 11:30
  • If only i can reply this with a simple 'k'.. – fa wildchild Feb 28 '23 at 03:39
  • `ssh -o 'StrictHostKeyChecking no' ...` from the accepted answer would be better. Why open the null file-descriptor, if no file is required. – Lockszmith Aug 23 '23 at 22:34
-5

Add following file

~/.ssh/config

and this in the file as content

StrictHostKeyChecking no

This setting will make sure that ssh will never ask for fingerprint check again. This should be added very carefully as this would be really dangerous and allow to access all fingerprints.

mario.van.zadel
  • 2,919
  • 14
  • 23
vishal sahasrabuddhe
  • 722
  • 7
  • 15
  • 6
    private internet, mb. I agree. Don't do this in a real world environment. – TamusJRoyce Mar 10 '19 at 16:08
  • 1
    Obviously, It is only for private network host within your internet VPC/network. A public facing host should not have this. – vishal sahasrabuddhe Mar 13 '19 at 06:25
  • 2
    This is very risky advice since it doesn't have a qualifier that this is a huge security hole and the instructions would add it globally rather than within, say, a `Host` block. – Chris Adams Mar 02 '20 at 20:58
  • @ChrisAdams I hope you saw my previous comment about when it should be added. – vishal sahasrabuddhe Mar 30 '20 at 11:49
  • 1
    @vishalsahasrabuddhe That's an important qualifier which is not in the original comment and it's still reckless because that will affect every SSH connection so you're gambling that nobody will ever change the usage patterns or copy that config somewhere else. It's safer to recommend either `StrictHostKeyChecking accept-new` or using `Host` to only weaken security for the intended servers. – Chris Adams Apr 17 '20 at 21:14
  • @ChrisAdams added the warning with the comment. – vishal sahasrabuddhe Apr 22 '20 at 07:33
  • @ChrisAdams not sure. How should I convey the message, I added solution and provided a warning too. – vishal sahasrabuddhe Apr 28 '20 at 06:32
  • perhaps my comments on other answers can help, but this is indeed a huge "don't even think of doing it". – cregox Jan 17 '21 at 19:21
  • You pretty much need something like this if you're targeting an embedded Linux system, with a read-only user directory, and where the embedded device changes fingerprint on every reboot. I found the `ssh-keygen -R` solution does the trick but generates some unwanted output noise. – Scott Prive Jun 24 '21 at 14:55
  • It is heartbreakng how many people advocate doing this without a big warning. – René Jahn Aug 22 '21 at 09:04