291

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...

3
  • 2
    Dó you use host names or IP-addresses? May 27, 2012 at 13:21
  • 1
    Not similar but I got the same error but due to a different problem: serverfault.com/questions/494916/…
    – zengr
    Aug 28, 2013 at 19:18
  • 1
    This is not an Ubuntu-specific issue. Can happen with any ssh from the command-line.
    – MarkHu
    Mar 31, 2017 at 17:19

20 Answers 20

320

"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?).

5
  • 23
    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, 2017 at 23:19
  • 2
    Unsurprisingly, ssh-keygen -R example.net:7999 yields Host example.net:7999 not found in known_hosts.
    – alex
    Feb 12, 2018 at 18:35
  • I removed known_hosts file and ssh again. It worked.
    – ParisaN
    Jun 6, 2018 at 10:49
  • file ~/.ssh/known_hosts is unreadable Aug 5, 2019 at 17:03
  • 1
    Works like a charm. Hostname can be the IP address as well. Thanks!
    – Pieter
    May 10, 2020 at 14:26
213

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 [email protected] uptime

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

10
  • 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.
    – Alain
    Nov 11, 2013 at 14:34
  • 18
    +1 For example, for Jenkins executions, this is a good solution. Thanks
    – Lobo
    Feb 5, 2015 at 10:02
  • 7
    @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"""
    – prayagupa
    Jun 8, 2017 at 21:40
  • 7
    This answer is really bad! There's absolutely no need to screw up your security like this! You can use ssh-keyscan manually to get the host key first. Package the result of this with your remote script and then use -o GlobalKnownHostsFile=... to use it automated. That way, if someone tries to spoof your server, the script won't blindly talk to the attacker! May 4, 2021 at 7:44
  • 3
    From the man page man7.org/linux/man-pages/man5/ssh_config.5.html ssh -o StrictHostKeyChecking=accept-new [email protected] uptime Will add a key to the known hosts if not found, otherwise verify the key is correct
    – Hovo
    Sep 21, 2022 at 3:59
19

Maybe you just need to enter "yes" when ssh confirm you want to continue connecting.

Like below:

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".

2
  • 1
    This solved it for me. In Ubuntu the default is yes so I was just hitting Enter in a Mac without reading and getting the error. Thanks!
    – SCL
    Mar 12, 2023 at 10:18
  • lol, this shit happens sometimes =) Dec 28, 2023 at 16:04
16

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.

1
  • 8
    +1 for advising to use -v parameter; this can help a lot when debugging ssh problems. Jul 24, 2012 at 19:10
14

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
2
  • 4
    Use ssh-keyscan -t rsa @targethost >> ~/.ssh/known_hosts to directly insert it in the known_hosts without having to manually copy it in there. With this, you do not have to use @MarkHu's ssh -o StrictHostKeyChecking=no [email protected] uptime anymore. Not sure, but it is even possible that this barely upvoted answer is the best of all. Feb 25, 2021 at 22:07
  • Yup Definitely the better than disabling known hosts. May 4, 2021 at 7:39
12

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
9

On terminal:

ssh -o StrictHostKeyChecking=no -i YourPublicKey.pem [email protected] 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 [email protected]
1
  • 1
    StrictHostKeyChecking should rarely, if ever, be disabled. You're just opening yourself up to possible MITM attacks. Mar 22, 2022 at 19:42
6

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.

1
  • As this command I am getting as suggestion in ubuntu 12.4.
    – MaNKuR
    May 31, 2015 at 18:09
4

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.

4

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>
1
  • Voting up, because this is fast temporary(!) solution to work without providing the key Jul 1, 2022 at 11:39
3

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.

2
  • 1
    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, 2016 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, 2016 at 16:44
3

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 [email protected] -p 4231                              // Try again

Hope this works.

2

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.

1

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.

1

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 [email protected]
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:sx1Z4xyGY9venBP6dIHAoBj0VhDOo7TUVCE2xWXpzQk.
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 192.168.0.45 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.

0
1

For most of the cases, the error msg returned by the Linux would have told you what to do. For instance in the earlier answer:

my_mac:~ oivanche$ sudo ssh [email protected]
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:sx1Z4xyGY9venBP6dIHAoBj0VhDOo7TUVCE2xWXpzQk.
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 192.168.0.45 has changed and you have requested strict checking.
Host key verification failed.

It says that the remote server host key has changed - therefore your previously stored local record DOES NOT MATCH any more. For security reasons the connection is not established.

The simplest solution would be just deleted the line mentioned (line 74) in your local pc in /var/root/.ssh/known_hosts by

sudo nano /var/root/.ssh/known_hosts

You would want to deleted the line mentioned ONLY. No easier way just use your keyboard cursor and backspace or delete keys.

Once deletion is done, save it by command Ctrl+o and quit the file by command Ctrl+x.

Now reconnect to your host via ssh, using something like this:

ssh -i /Users/ben/document/key.pem [email protected]

where /Users/ben/document/key.pem is your server's key pair you had set to use (can't find it anymore? go to the hosting site to regenerate one) and 192.168.0.45 is your remote server IP you are connecting to.

When prompted with something like are you sure you want to add the host key permanently to this machine? type yes. Then you have updated your local key for connecting to the remote server for good.

Hope this clarifies and helps.

0

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

1
  • 8
    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, 2014 at 20:52
0

when this is on the screen: "Are you sure you want to continue connecting (yes/no)?" you need to enter yes, instead of pressing the enter or return key try this!

0

Find the .ssh folder for your user.

cd /home/<user>/.ssh  

Eg : If the user is jenkins,

cd /home/jenkins/.ssh

Then open the known_hosts file.

vi known_hosts

Search your remote server IP address and delete that row.

save the file and connect!

-1
chmod 666 /dev/tty 

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

You must log in to answer this question.

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