Git error when connecting to remote repository: "Host key verification failed"

Question

I'm trying to connect to a remote Git repository that resides on my web server and clone it to my computer.

My command uses the following format:

git clone ssh://username@domain.example/repository.git

This works well for most of my team members. Normally after running this command, Git will prompt for the user password and then run the clone. However, when running on one of my machines, I get the following error:

Host key verification failed.

FATAL: Unable to read from remote repository.

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

Answer 1

As I did previously in cloning the git repository resulted in the error - Host key verification failed. fatal: The remote end hung up unexpectedly , adding 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 the clone URL. With SSH, each host has a key. The client remembers the host key associated with a specific address and refuses the connection if the host key changes. This prevents man-in-the-middle attacks.

The host key for

domain.example has been changed. If you feel this is not suspicious , remove the old key domain.example## from your local cache by editing ${HOME}/.ssh/known_hosts and removing the line # Or let the SSH utility do it for you

ssh-keygen -R domain.example

From here, you can record the updated key yourself

ssh-keyscan -t rsa domain.example >> ~/.ssh/known_hosts

Or, equivalently, have

ssh do it for you the next time you connect using git fetch, git pull or git Push (or even a plain ssh domain.example), answer "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 that

domain.example is no longer in your known_hosts after deletion, and may not be in the system's /etc/ssh/ssh_known_hosts, so ssh has no way of knowing whether the host on the other end of the connection is actually domain.example. (If the key in /etc is wrong, someone with administrative rights will have to update the system-wide file.)

I strongly recommend that you consider letting users authenticate using keys as well. This way

ssh-agent can store the key material for convenience (rather than everyone having to enter the password every time they connect to the server), and the password is not transmitted over the network.