Host Key Verification Failed.

$ lftp sftp://user@1.2.3.4:21 Password: lftp user@1.2.3.4: ls ls: Fatal error: Host key verification failed The cause of the problem is the missing RSA key fingerprint in the list of known hosts. To fix it, it's enough to try to connect to the SFTP server using the ssh command. Mac OS X Remove SSH Known Host last updated December 15, 2009 in Categories BASH Shell. Host key verification failed. How do I fix this problem under Mac OX X? Host key verification failed. If you are sure that it is harmless and the remote host key has been changed in a legitimate way, you can skip the host key checking by sending the key to a null knownhosts file.

Host Key Verification Failed. Lost Connection
Host Key Verification Failed. Github

Trying to ssh into a computer I control, I'm getting the familiar message:

I did indeed change the key. And I read a few dozen postings saying that the way to resolve this problem is by deleting the old key from the known_hosts file.

But what I would like is to have ssh accept both the old key and the new key. The language in the error message ('Add correct host key') suggests that there should be some way to add the correct host key without removing the old one.

I have not been able to figure out how to add the new host key without removing the old one.

Is this possible, or is the error message just extremely misleading?

chicks

3,0907 gold badges20 silver badges33 bronze badges

Samuel Edwin WardSamuel Edwin Ward

8532 gold badges7 silver badges12 bronze badges

10 Answers

get the rsa key of your server, where server_ip is your server's IP address, such as 192.168.2.1:
Sample response:
and on the client, copy the entire response line server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG..., and add this key to the bottom of your ~/.ssh/known_hosts file:

quantaquanta

43.9k15 gold badges117 silver badges197 bronze badges

Remove that the entry from known_hosts using:

This will remove the problematic IP or hostname from known_hosts file and try to connect again.

From the man pages:

-R hostname
Removes all keys belonging to hostname from a known_hosts file. This option is useful to delete hashed hosts (see the -H option above).

Luis AbarcaLuis Abarca

A very simple way is:

Then edit known_hosts to clear the original key, then ssh to the host using:

It'll add the new key automatically; then compare the two files. A program such as meld is a nice way to compare the two files. Then merge the files to make known_hosts contain both keys

My 'reason' for keeping two keys is that the destination system is multiboot, even though I dare say there's a way of synchronizing the keys across the installations, it seems more straightforward to allow multiple keys.

EDIT 2015/06

I should add, revisiting it now, that I notice an even simpler way [as long as the entry is identifiable, normally from the hostname / IP address quite aside from the error message referencing its specific location];

Edit known_hosts to add # at the start of the 'old' entry inknown_hosts temporarily
Connect [ssh to the host], agree to the prompt to add the new key 'automatically'
Then re-edit known_hosts to remove the #

There's even the option HostKeyAlias as in

then subsequently, after ssh client adds the new key under the alias, you may either edit known_hosts to substitute the 'real' hostname/IP address for the alias or connect to that incarnation of that host with the alias option evermore

MarkMark

I have the same issue with a raspberry pi which I boot with several different systems (dev system for compiling arm binaries, project, xbmc, etc.) and have run into the same problem. They use DHCP on a local network and my router always reused the same IP since the MAC address was the same. I've solved it by using different domain names in my hosts file:

The known_hosts file saves fingerprints by host name so even though it is the same IP address, each unique host name gets a different entry.

I got sick of adding the names to hosts files every time I used a new system so I came up with an even lazier way by using leading zeros on ip addresses like:

Each variation of the (uncanonicalized) ip address gets it's own entry in known_hosts.

MikeMike

If both your client and server have OpenSSH 6.8 or newer, you can use the UpdateHostKeys yes option in your ssh_config or ~/.ssh/config. For example:

This makes SSH store all host keys that the server has to known_hosts, and when a server changes or removes one host key, the key is also changed or removed in your known_hosts.

Falcon Momot

22.8k10 gold badges52 silver badges80 bronze badges

MikaelaMikaela

I don't see why you want to work with two keys, but you can certainly add more than one valid key to the ~/.ssh/known_hosts file, but you will have to do it manually.

Another solution might be to use the StrictHostKeyChecking=no option for this specific host:

which you could put into an alias in your ~/.profile or something similar.

Sven♦Sven

88.9k10 gold badges153 silver badges203 bronze badges

If you only ssh onto a local network then...

A simple solution is to wipe the old key file and replace it with a blank one. This will allow you to reauthorise all of your connections with new keys. If you have ssh keys stored for sites outside your local network, then you need to ensure that your initial connection is safe as you did the first time you connected to that server.

Then press space, backspace cntl+x and 'y' to save the new buffer (file). Its bad practise but okay providing you aren't regularly ssh'ing outside your local network (eg a uni or work server)

On a secure local network this is safe because you simply cant get a man in the middle attack.

Its always better to use code you understand!

AaronAaron

So many answers, but so many that give up protection by turning off strict host checking totally, or destroying unrelated host info or just forcing the user to interactively accept keys, possibly at a later point, when it is unexpected.

Here's a simple technique to allow you to leave strict host checking on, but update the key in a controlled way, when you expect it to change:

Remove the old key and update in one command
Repeat with IP address(es) or other host names if you use them.

The advantage of this approach is that it rekeys the server exactly once. Most versions of ssh-keygen seem to not return an error if the server you try to delete doesn't exist in the known hosts file, if this is a problem for you, use the two commands in sequence.

This approach also verifies connectivity and emits a nice message for logs in the ssh command (which logs in, updates the host key, and outputs SSH host key updated then immediately exits.

If your version of ssh-keygen returns a non-zero exit code, and you prefer to handle this without error, regardless or prior connection, simply use the two commands in sequence, ignoring any errors on the ssh-keygen command.

If you use this technique, you never need to vary your ssh command, or turn off host checking except during that one ssh command. You can be sure that future ssh sessions will work without conflict or needing to explicitly accept a new key, as long as the ssh command above ran without error.

markgo2kmarkgo2k

I had the same problem.

All I did was sudo nano /home/user/.ssh/ host_allow and erased the key.