4

When I use scp between the VM1 and VM2 , there is no problem, because of other reason I removed the VM2, and rebuild it by VMware workstation, when I use the scp to copy the file from the VM1 to the new VM2, there goes the issue:

# scp /home/iso/********.iso root@192.168.1.***:/home/  

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@  
@    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  
df:33:37:b6:7b:c9:e5:19:65:f7:38:ad:94:b2:9e:36.  
Please contact your system administrator.  
Add correct host key in /root/.ssh/known_hosts to get rid of this message.  
Offending ECDSA key in /root/.ssh/known_hosts:1  
ECDSA host key for 192.168.1.*** has changed and you have requested strict checking.  
Host key verification failed.  
lost connection 
3

The mentioned warning is that the fingerprint that the remote host has been changed since the first time you have logged there. Also the warning states which is the offending record in known_hosts. Offending ECDSA key in /root/.ssh/known_hosts:1 this states that the first line in known_host is offending.

You could remove it by executing ssh-keygen -R 192.168.1.xxx or with vi +1 /root/.ssh/known_hosts

Fingerprint is generated from keys that exist in the /etc/ssh/ by hashing them. After accepting in the first connection it is added in known_host and evaluate during log in.

edit 1

If you have multiple entires for the targer server like domain, domain.foo, 1.2.3.4 all should be removed and enter them by manualy by executing the command you try to use such as ssh/sftp etc .

Also you can add the keys from the remote host with ssh-keyscan that will give you the fingerprints and store them to known_hosts. However the fingerprint logic is that you should verify the remote before add it to known_host

  • ssh-keygen -R "$remotehost" did the trick, quick and easy. Didn't have much luck with ssh-keyscan though. – voices Apr 26 '18 at 7:03
4

Because you rebuild the VM2, the key in VM1 is different with the newer VM.

You should delete the /root/.ssh/known_hosts.


EDIT

As Hunter recommend, you can open the known_hosts file to find the associated key, then delete that line.

  • 1
    Probably not everything from known_hosts. Only the line which is deprecated. In the case of OP, it is line #1. – Hunter.S.Thompson Jul 19 '17 at 10:08
-1

Every time you install a new OS, a new SSH server is installed also. When the SSH server is installed, it generates a new, random key.

Your SSH client wants to make sure that it is connecting to the correct server, so it either asks you to confirm that key's fingerprint, or it compares with an existing entry in a file named known_hosts.

The big loud warning is there because under normal circumstances - where you have not re-installed - somebody who is trying to eavesdrop has faked the address of the server, but could not fake the key (it is impossible).

As long as you are sure that the server has been re-installed, you can simply delete the known_hosts file with the command:

rm $HOME/.ssh/known_hosts

And then you will be asked to confirm the new key, after which you can connect successfully.

  • 1
    No, do not delete all the known hosts. Delete only the one of that server. – Jakuje Jul 19 '17 at 10:21

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.