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...
20 Answers
"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?).
-
21It can also mean that you simply don't have the host key of the remote host. For example, if I
rm ~/.ssh/*, thenssh -o BatchMode=yes root@somewhere, if nothing else is wrong I will getHost key verification failed.Not important if you're always interactive, but relevant for scripts encountering the same error.– Ron BurkApr 25, 2017 at 23:19 -
2Unsurprisingly,
ssh-keygen -R example.net:7999yieldsHost example.net:7999 not found in known_hosts.– alexFeb 12, 2018 at 18:35 -
-
-
1
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.
-
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.– AlainNov 11, 2013 at 14:34
-
18
-
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"""Jun 8, 2017 at 21:40 -
6This answer is really bad! There's absolutely no need to screw up your security like this! You can use
ssh-keyscanmanually 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 -
2From the man page man7.org/linux/man-pages/man5/ssh_config.5.html
ssh -o StrictHostKeyChecking=accept-new [email protected] uptimeWill add a key to the known hosts if not found, otherwise verify the key is correct– HovoSep 21, 2022 at 3:59
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".
-
1This 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!– SCLMar 12 at 10:18
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.
-
7+1 for advising to use -v parameter; this can help a lot when debugging ssh problems. Jul 24, 2012 at 19:10
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
-
4Use
ssh-keyscan -t rsa @targethost >> ~/.ssh/known_hoststo directly insert it in the known_hosts without having to manually copy it in there. With this, you do not have to use @MarkHu'sssh -o StrictHostKeyChecking=no [email protected] uptimeanymore. Not sure, but it is even possible that this barely upvoted answer is the best of all. Feb 25, 2021 at 22:07 -
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
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]
answered Mar 27, 2017 at 0:50
-
1
StrictHostKeyCheckingshould rarely, if ever, be disabled. You're just opening yourself up to possible MITM attacks. Mar 22, 2022 at 19:42
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.
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.
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>
-
Voting up, because this is fast temporary(!) solution to work without providing the key Jul 1, 2022 at 11:39
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.
-
1No, 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.– techrafMar 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.GMar 14, 2016 at 16:44
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.
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.
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.
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.
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.
pico ~/.ssh/known_hosts and delete all lines, after just reconnect and you will get a new key.
-
8This is a dangerous solution, because you will remove ALL your host keys. The accepted solution,
ssh-keygen -R hostnameis better.– msanfordMar 24, 2014 at 20:52
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!
How to Fix Warning Remote Host Identification Has Changed
Resolve ssh login issue with one command ssh-keygen -R HostName
or Watch Video:- https://youtu.be/sq_5ID3KV9Q
chmod 666 /dev/tty
is yet another tty solution - sometimes, this device file has wrong permissions.
sshfrom the command-line.