How can I force ssh to accept a new host fingerprint from the command line?

Question

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?

Answer 1

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

Answer 2

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

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.

Answer 3

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.

Answer 4

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

Answer 5

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"

Answer 6

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

Answer 7

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.