Git error: "Host Key Verification Failed" when connecting to remote repository

Question

I am trying to connect to a remote Git repository that resides on my web server and clone it to my machine.

I am using the following format for my command:

git clone ssh://[email protected]/repository.git 

This has worked fine for most of my team members. Usually after running this command Git will prompt for the user's password, and then run the cloning. However, when running on one of my machines I get the following error:

Host key verification failed.

fatal: Could not read from remote repository.

We are not using SSH keys to connect to this repository, so I'm not sure why Git is checking for one on this particular machine.

Answer 1

As I answered previously in Cloning git repo causes error - Host key verification failed. fatal: The remote end hung up unexpectedly, add GitHub to the list of known hosts:

ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts 

Answer 2

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.com 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.com or letting an SSH utility do it for you with

ssh-keygen -R domain.com 

From here, record the updated key either by doing it yourself with

ssh-keyscan -t rsa domain.com >> ~/.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.com) by answering yes when prompted

The authenticity of host 'domain.com (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.com 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.com. (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.