You are connecting via the SSH protocol, as indicated by the ssh:// prefix on your clone URL. Using SSH, every host has a key. Clients remember the host key associated with a particular address and refuse to connect if a host key appears to change. This prevents man in the middle attacks.
The host key for domain.example has changed. If this does not seem fishy to you, remove the old key from your local cache by editing ${HOME}/.ssh/known_hosts to remove the line for domain.example or letting an SSH utility do it for you with
ssh-keygen -R domain.example
From here, record the updated key either by doing it yourself with
ssh-keyscan -t rsa domain.example >> ~/.ssh/known_hosts
or, equivalently, let ssh do it for you next time you connect with git fetch, git pull, or git push (or even a plain ol’ ssh domain.example) by answering yes when prompted
The authenticity of host 'domain.example (a.b.c.d)' can't be established. RSA key fingerprint is XX:XX:...:XX. Are you sure you want to continue connecting (yes/no)?
The reason for this prompt is domain.example is no longer in your known_hosts after deleting it and presumably not in the system’s /etc/ssh/ssh_known_hosts, so ssh has no way to know whether the host on the other end of the connection is really domain.example. (If the wrong key is in /etc, someone with administrative privileges will have to update the system-wide file.)
I strongly encourage you to consider having users authenticate with keys as well. That way, ssh-agent can store key material for convenience (rather than everyone having to enter her password for each connection to the server), and passwords do not go over the network.
The RSA key on the Openbridge Server was changed and your SSH client is warning you that the discrepancy might be the fault of an attacker.
This guide will help resolve SSH connection issues that produce the following error:
Why does this error occur?
This error occurs when the target server you are trying to SSH into has been rebuilt or had it’s RSA key changed since the last time you connected to it. Whenever you connect to a server via SSH, that server’s public key is stored in your home directory (or possibly in your local account settings if using a Mac or Windows desktop) file called known_hosts .
When you reconnect to the same server, the SSH connection will verify the current public key matches the one you have saved in your known_hosts file. If the server’s key has changed since the last time you connected to it, you will receive the above error (or one similar to it).
While contacting your system administrators when any odd warning message occurs is a good idea, you are safely able to resolve this issue yourself:
First, locate your known_hosts file, and open in a general text editor. The error will often give you the location of the known_hosts file you need to change. In the example above the offending RSA key is located here: /home/ec2-user.ssh/known_hosts:222
Linux and Mac Users
Linux users will find this file in their home directory, in the ~/.ssh/ directory. You use sed to remove the offending line. Run something like sed -i '222d' ~/.ssh/known_hosts which will remove the offending line as reported in our example
Mac users will find this in either their local account’s ~/.ssh folder, or their network home directory as with Linux users. You can also run sed -i '222d' ~/.ssh/known_hosts
You can also use the IP address with sed like this sed -i '/1.2.3.4/d' /home/ec2-user/.ssh/known_hosts
Another option is to user ssh-keygen with the -R option. This removes all keys belonging to hostname from a known_hosts file. This option is useful to delete hashed hosts. If your remote hostname is server.openbridge.com
Lastly, you can edit your known_hosts with a text editor and remove the offending line. For example, using vi
Type vi ~/.ssh/known_hosts . Go to line 222 and then dd to delete and then wq to save.
Windows Users
Windows users have several places this can be changed. Common places are ~\Users\~\AppData\Roaming\_ssh\ or the SSH client’s configuration settings. This also might be in a location like C:\Users\username\.ssh or C:\cygwin64\home\bob\.ssh\known_hosts . The specific location will be a function of your Windows environment.
Similar to the Mac and Linux examples, you want to remove the offending SSH key reference:
The next time you attempt to log in, SSH should tell you that the host key is unknown and ask if you want to connect and save the new key.
You are connecting via the SSH protocol, as indicated by the ssh:// prefix on your clone URL. Using SSH, every host has a key. Clients remember the host key associated with a particular address and refuse to connect if a host key appears to change. This prevents man in the middle attacks.
The host key for domain.example has changed. If this does not seem fishy to you, remove the old key from your local cache by editing ${HOME}/.ssh/known_hosts to remove the line for domain.example or letting an SSH utility do it for you with
ssh-keygen -R domain.example
From here, record the updated key either by doing it yourself with
ssh-keyscan -t rsa domain.example >> ~/.ssh/known_hosts
or, equivalently, let ssh do it for you next time you connect with git fetch, git pull, or git push (or even a plain ol’ ssh domain.example) by answering yes when prompted
The authenticity of host 'domain.example (a.b.c.d)' can't be established. RSA key fingerprint is XX:XX:...:XX. Are you sure you want to continue connecting (yes/no)?
The reason for this prompt is domain.example is no longer in your known_hosts after deleting it and presumably not in the system’s /etc/ssh/ssh_known_hosts, so ssh has no way to know whether the host on the other end of the connection is really domain.example. (If the wrong key is in /etc, someone with administrative privileges will have to update the system-wide file.)
I strongly encourage you to consider having users authenticate with keys as well. That way, ssh-agent can store key material for convenience (rather than everyone having to enter her password for each connection to the server), and passwords do not go over the network.
As a security precaution, SSH keeps track of which hosts it has previously seen.
This error means that the server to which you’re connecting presented a key that doesn’t match the keys seen for this server in the past.
You may see this error if the server has changed its keys unexpectedly, in which case you should be able to find an official report from a trustworthy source announcing the change. If GitHub changes its SSH host key, this will be announced on the GitHub Blog at github.blog.
You can find an up-to-date list of GitHub’s public SSH keys on GitHub Docs. You may need to add these keys to your known_hosts file. For more information, see «GitHub’s SSH key fingerprints.»
If you are encountering the error but can’t find an official source for the server’s keys, it is safest not to connect, because you may be connecting to a server other than your intended server. You may want to contact your IT department or the server’s support team for help. If the server is being impersonated, the owner of the server will appreciate you informing them.
What happens in background when you connect a server first time using ssh
When you connect to a server for the first time, the server prompts you to confirm that you are connected to the correct system. The following example uses the ssh command to connect to a remote host named host03:
# ssh host03 The authenticity of host 'host03 (192.0.2.103)' can’t be established. ECDSA key fingerprint is ... Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'host03,192.0.2.103' (ECDSA) to the list of known hosts.
Host validation is one of OpenSSH’s major features. The command checks to make sure that you are connecting to the host that you think you are connecting to. When you enter yes, the client appends the server’s public host key to the user’s ~/.ssh/known_hosts file, creating the ~/.ssh directory if necessary. The next time you connect to the remote server, the client compares this key to the one the server supplies. If the keys match, you are not asked if you want to continue connecting.
If someone tries to trick you into logging in to their machine so that they can sniff your SSH session, you will receive a warning similar to the following:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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 the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
dd:cf:50:31:7a:78:93:13:dd:99:67:c2:a2:19:22:13.
Please contact your system administrator.
Add correct host key in /home/user01/.ssh/known_hosts to get rid of this message.
Offending key in /home/lcz/.ssh/known_hosts:7
RSA host key for 192.168.219.149 has changed and you have requested strict checking.
Host key verification failed.
If you ever get a warning like this, stop and determine whether there is a reason for the remote server’s host key to change (such as if SSH was upgraded or the server itself was upgraded). If there is no good reason for the host key to change, do not try to connect to that machine until you have resolved the situation.
How to correct the “host key verification failed” error
Method 1 – removing old key manually
1. On the source server, the old keys are stored in the file ~/.ssh/known_hosts.
2. Only if this event is legitimate, and only if it is precisely known why the SSH server presents a different key, then edit the file known_hosts and remove the no longer valid key entry. Each user in the client/source server has its own known_hosts in its home directory, just remove the entry in the file of a specific user for the destination server. For example:
– If root wants to ssh to the server, just removing entry in the /root/.ssh/known_hosts file is all right.
– If testuser wants to ssh to the server, then remove the entry in the file /home/testuser/.ssh/known_hosts.
3. In my case, I will remove the the key (highlighted in red) for the destination server 192.168.219.149 from the file /home/user01/.ssh/known_hosts.
# vim /home/user01/.ssh/known_hosts
172.104.9.113 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBLrY91bQOihgFZQ2Ay9KiBG0rg51/YxJAK7dvAIopRaWzFEEis3fQJiYZNLzLgQtlz6pIe2tj9m/Za33W6WirN8=
192.168.219.148 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBCrY/m16MdFt/Ym51Cc7kxZW3R2pcHV1jlOclv6sXix1UhMuPdtoboj+b7+NLlTcjfrUccL+1bkg8EblYucymeU=
192.168.219.149 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBCrY/m16MdFt/Ym51Cc7kxZW3R2pcHV1jlOclv6sXix1UhMuPdtoboj+b7+NLlTcjfrUccL+1bkg8EblYucymeU=
Method 2 – removing old key using the ssh-keygen command
You can also remove the old key using the ssh-keygen command as well. The syntax to use the command is below.
$ ssh-keygen -R [hostname|IP address]
For example, In our case we will use the IP address to delete the old key.
$ ssh-keygen -R 192.168.219.149 # Host 192.168.219.149 found: line 3 /home/user01/.ssh/known_hosts updated. Original contents retained as /home/user01/.ssh/known_hosts.old
Note : If you do not know precisely, why the SSH server presents a different key, either your known_hosts file is incorrect, or somebody must investigate this server and the network connections to understand the reason of the unexpected change.
Verify
If the remote servers asks for a confirmation to add the new key to the ~/.ssh/known_host file, it confirms that you have successfully removed the old key. If you confirm the request, the source machine adds the new key into the ~/.ssh/known_host file.
$ ssh root@192.168.219.149 The authenticity of host '192.168.219.149 (192.168.219.149)' can't be established. ECDSA key fingerprint is SHA256:V+iGp3gwSlnpbtYv4Niq6tcMMSZivSnYWQIaJnUvHb4. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.219.149' (ECDSA) to the list of known hosts.