I can connect to another Ubuntu machine in my LAN via SSH. On both of then PC's I installed openssh-server but from another Ubuntu computer I can not connect to my PC via SSH and I got this error:

Host key verification failed...

17 Answers 17


"Host key verification failed" means that the host key of the remote host was changed.

SSH stores the host keys of the remote hosts in ~/.ssh/known_hosts. You can either edit that text file manually and remove the old key (you can see the line number in the error message), or use

ssh-keygen -R hostname

From man page:

-R hostname
Removes all keys belonging to hostname from a known_hosts file. This option is useful to delete hashed hosts .

(which I learned from the answer to Is it possible to remove a particular host key from SSH's known_hosts file?).

| improve this answer | |
  • 8
    It can also mean that you simply don't have the host key of the remote host. For example, if I rm ~/.ssh/*, then ssh -o BatchMode=yes root@somewhere, if nothing else is wrong I will get Host key verification failed. Not important if you're always interactive, but relevant for scripts encountering the same error. – Ron Burk Apr 25 '17 at 23:19
  • Unsurprisingly, ssh-keygen -R example.net:7999 yields Host example.net:7999 not found in known_hosts. – alex Feb 12 '18 at 18:35
  • I removed known_hosts file and ssh again. It worked. – ParisaN Jun 6 '18 at 10:49
  • file ~/.ssh/known_hosts is unreadable – João Pimentel Ferreira Aug 5 '19 at 17:03
  • Works like a charm. Hostname can be the IP address as well. Thanks! – Pieter May 10 at 14:26

If you are running in certain remote/scripting situations where you lack interactive access to the prompt-to-add-hostkey, work around it like this:

$ ssh -o StrictHostKeyChecking=no user@something.example.com uptime

Warning: Permanently added 'something.example.com,' (RSA) to the list of known hosts.

| improve this answer | |
  • 6
    +1, this is an ugly solution, but in some cases of automated monitoring processes that work with dymaic ip-connected devices, this is a simple and acceptable solution. – Ninsuo Nov 11 '13 at 14:34
  • 14
    +1 For example, for Jenkins executions, this is a good solution. Thanks – Lobo Feb 5 '15 at 10:02
  • 5
    @Lobo can't agree more, i am using it for jenkins, which is cool sh """ssh -o StrictHostKeyChecking=No ec2-user@someIpAddress-e2e sudo service tomcat restart""" – prayagupd Jun 8 '17 at 21:40
  • Saved My Life. Life saver solution. – user1735921 Oct 12 '17 at 6:43
  • Saved my life. I was having trouble with a script that runs as a system service. When I was looking at the logs, my script was printing always this error. When I start ssh inside my script with this option, there is no this error any more. – Mubin Icyer Sep 1 at 13:35

Also sometimes there is situation when you are working on serial console, then checking above command in verbose mode -v will show you /dev/tty does not exist, while it does.

ssh -v user@hostname

In above case just remove /dev/tty and create a symlink of /dev/ttyS0 to /dev/tty.

rm /dev/tty
ln -s /dev/ttyS0 /dev/tty

As an alternative, add id_rsa.pub to the remote location, so password is not prompted and you get login access.

| improve this answer | |
  • 6
    +1 for advising to use -v parameter; this can help a lot when debugging ssh problems. – daniel kullmann Jul 24 '12 at 19:10

In my case, this was caused by a udev problem - there was no /dev/tty device node. The solution for me was just:

sudo mknod -m 666 /dev/tty c 5 0
| improve this answer | |

On terminal:

ssh -o StrictHostKeyChecking=no -i YourPublicKey.pem user@example.com uptime

The following message, or similar, will appear:

Warning: Permanently added 'example.com, XX.XXX.XXX.XX' (ECDSA) to the list of known hosts.
 00:47:37 up 3 min,  0 users,  load average: 0.00, 0.00, 0.00

Then, connect to your EC2 as normal:

ssh -i YourPublickey.pem user@example.com
| improve this answer | |
  • I got command-line line 0: Bad yes/no/ask argument. because you wrongly use 'No' instead of 'no' as argument to StrictHostKeyChecking – Axel Bregnsbo Aug 25 '18 at 15:30

May be you just need to enter "yes" when ssh confirm you want to continue connectting.

Like bellow.

The authenticity of host 'xxx' can't be established.
ECDSA key fingerprint is yyy.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'xxx' (ECDSA) to the list of known hosts.
Enter passphrase for key '/Users/ysy/.ssh/id_rsa':

Then enter your password.

Please pay attention to "Are you sure you want to continue connecting (yes/no)? yes". You must enter yes, not enter.

| improve this answer | |
  • 1
    Wow. I can't believe this worked. lol. I kept pressing enter. The instruction to type yes should be more explicit – Emmanuel N K Jun 18 at 8:52

Well, it simply because the second ubuntu requires connection by key and not password.

I suggest you use sudo dpkg-reconfigure openssh-server on your pc, and then it should work properly. It will reset the configuration for openssh and should come back to a default password authentication.

Second possibility is that there's already a key for your other ubuntu in you PC, and that it changed thus being not recognized anymore. In this case, you'll have to edit the file .ssh/authorized_keys to remove the problematic line identifying your ubuntu.

| improve this answer | |

This is an old thread and I just ran across this answer, I will just add what I did to solve this.

ssh-keygen -f "/home/USER/.ssh/known_hosts" -R HOSTNAME

I just looked at the error message that it threw at me and it said to run that command in order to remove it from the list of hosts. After that I did the following:

ssh-copy-id HOSTNAME

Than I followed the prompts from there until I was able to ssh into the server.

| improve this answer | |
  • As this command I am getting as suggestion in ubuntu 12.4. – MaNKuR May 31 '15 at 18:09

Its means your remote host key was changed (May be host password change),

Your terminal suggested to execute this command as root user

$ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net]:4231

You have to remove that host name from hosts list on your pc/server. Copy that suggested command and execute as a root user.

$ sudo su                                                            // Login as a root user

$ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net]:4231   // Terminal suggested command execute here
Host [www.website.net]:4231 found: line 16 type ECDSA
/root/.ssh/known_hosts updated.
Original contents retained as /root/.ssh/known_hosts.old

$ exit                                                               // Exist from root user

$ sudo ssh root@www.website.net -p 4231                              // Try again

Hope this works.

| improve this answer | |

You should change your key in this way: From your given error find which host-key changed for example: Offending ECDSA key in /Users/user-name/.ssh/known_hosts:5 said 5th key changed, so do this:

sed -i '5d' ~/.ssh/known_hosts

Notice: you must be root or have privilege for sudo.

| improve this answer | |
  • No, unless you are doing it for someone else, it does not require root nor sudo. You are editing the file in your home directory. Second: for the command to work it requires GNU sed. – techraf Mar 13 '16 at 16:00
  • Maybe you right but I tried to ssh from Mac OSX to ubuntu-server and I have to do that. by the way thank you for your comment. – Amir.A.G Mar 14 '16 at 16:44

you have to put the rsa key of the target host into the source host /home/user/.ssh/known_hosts by running this on the target

ssh-keyscan -t rsa @targethost
| improve this answer | |

Other than strictly disable host key checking, you can also connect by typing:

ssh -o LogLevel=quiet -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no <username@target_machine_ip_or_domain_name>
| improve this answer | |

Just do "sudo vi /var/root/.ssh/known_hosts" and remove the line, that holds a key for a host you're trying to connect to and reconnect again.

I don't know about your particular situation, but most probably this error came along with a message like this:

my_mac:~ oivanche$ sudo ssh pi@
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
Please contact your system administrator.
Add correct host key in /var/root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /var/root/.ssh/known_hosts:74
ECDSA host key for has changed and you have requested strict checking.
Host key verification failed.

If you'll read the log more carefully you'll see that the key you've got from a host is conflicting with a key you already have - in this case it's on line 74 of known_hosts file (Offending ECDSA key in /var/root/.ssh/known_hosts:74). Remove the line from the known_hosts, save changes and reconnect.

| improve this answer | |
  • this helped me - thanks – Karan Desai Dec 3 '19 at 14:19

pico ~/.ssh/known_hosts and delete all lines, after just reconnect and you will get a new key.

| improve this answer | |
  • 6
    This is a dangerous solution, because you will remove ALL your host keys. The accepted solution, ssh-keygen -R hostname is better. – msanford Mar 24 '14 at 20:52

My solution comes from this blog post: Algorithm negotiation failed for SSH Secure Shell Client

You need to modify the file as follows:

sudo nano /etc/ssh/sshd_config

And then add the following:

# Ciphers
Ciphers aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,arcfour
KexAlgorithms diffie-hellman-group1-sha1

Basically you tried different solutions until you find one which can solve your problem. If the above solutions don't work, please try this one. If this one doesn't work as well, please try others.

| improve this answer | |

If you add the -v option to ssh (possibly more than once) it will print all sorts of stuff which may help in identifying the problem. In my case it complained about /dev/tty permissions, and chmod 666 /dev/tty fixed the problem.

| improve this answer | |
chmod 666 /dev/tty 

is yet another tty solution - sometimes, this device file has wrong permissions.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.