Ошибка Git: «Ошибка проверки ключа хоста» при подключении к удаленному репозиторию

Я пытаюсь подключиться к удаленному Git-репозиторию, который находится на моем веб-сервере, и клонировать его на мою машину.

Я использую следующий формат для моей команды:

Это хорошо сработало для большинства членов моей команды. Обычно после выполнения этой команды Git запрашивает пароль пользователя, а затем запускает клонирование. Однако при работе на одном из моих компьютеров я получаю следующую ошибку:

Проверка ключа хоста не удалась.

Неустранимый: Не удалось прочитать из удаленного хранилища.

Мы не используем ключи SSH для подключения к этому хранилищу, поэтому я не уверен, почему Git проверяет его на этой конкретной машине.

Вы подключаетесь по протоколу SSH, как указано ssh:// префиксом в вашем URL-адресе клона. Используя SSH, у каждого хоста есть ключ. Клиенты запоминают ключ хоста, связанный с конкретным адресом, и отказываются подключаться, если ключ хоста меняется. Это мешает человеку в середине атаки.

Ключ хоста для domain.com изменился. Если вам это не кажется странным , удалите старый ключ из локального кэша, отредактировав его, $/.ssh/known_hosts чтобы удалить строку для domain.com, или разрешив утилите SSH сделать это за вас с помощью

Отсюда запишите обновленный ключ, либо сделав его самостоятельно с

или, что то же самое, пусть ssh сделает это за вас в следующий раз , когда вы соединиться с git fetch , git pull или git push (или даже простой ПР» ssh domain.com ), отвечая да , когда будет предложено

Причиной этого запроса является то, что domain.com больше не находится в вашем known_hosts после удаления и, вероятно, не в системе /etc/ssh/ssh_known_hosts , поэтому ssh не может узнать, действительно ли хост на другом конце соединения является domain.com. (Если введен неправильный ключ /etc , кто-то с правами администратора должен будет обновить общесистемный файл.)

Я настоятельно рекомендую вам также рассмотреть возможность аутентификации пользователей с помощью ключей. Таким образом, ssh-agent можно хранить материал ключа для удобства (вместо того, чтобы каждый должен был вводить свой пароль для каждого соединения с сервером), и пароли не передаются по сети.

How to fix the error “host key verification failed”

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:

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.

What causes host key verification failed error

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:

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

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.

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.

For example, In our case we will use the IP address to delete the old key.

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

exited with an unexpected code: 128. Host key verification failed. fatal: Could not read from remote repository. #4479

Comments

deed02392 commented Apr 20, 2018

Description

Just installed GitHub Desktop fresh. I opened a local cloned repo, commited a change and tried to push.

I suspect the issue is in the git binary that GH desktop is using.

Version

• GitHub Desktop:
  1.1.1
• Operating system:
  Microsoft Windows [Version 10.0.16299.371]

Steps to Reproduce

Install GitHub Desktop fresh. I opened a local cloned repo, commited a change and tried to push.

Expected Behavior

Actual Behavior

Authentication error modal

Additional Information

Have installed git for windows, git in cygwin and gitkraken. All these work in their own respective environments.

Relevant excerpt provided above

The text was updated successfully, but these errors were encountered:

steveward commented Apr 20, 2018

Thanks for opening this @deed02392. The Host key verification failed error usually indicates an issue with SSH — did you clone this repository in GitHub Desktop, or did you clone it from another client using SSH?

deed02392 commented Apr 20, 2018

I think I cloned it using GitKraken. I hope this helps.

steveward commented Apr 20, 2018

@deed02392 thanks for the update. You can check the remote URL the repository is using from GitHub Desktop by going to the file menu and selecting Repository > Repository Settings > Remote . Let me know what that shows.

steveward commented Apr 20, 2018

@deed02392 that’s all the information I needed, and it does indicate that this repository is using SSH.

There are two solutions for this:

1. Switch the remote URL to use HTTPS instead of SSH (you should not have any authentication issues as long as you are logged in with your GitHub Enterprise account in GitHub Desktop).
2. Get SSH working. The host key verification failed error means that the host key from GitHub Enterprise isn’t in your known_hosts file. You should be able to fix this by running the following command from Git Bash:

Replace with the URL of the GitHub Enterprise server you are connecting to.

Hope that helps. Let me know if that doesn’t get things working.

deed02392 commented Apr 20, 2018 •

Thanks. Switching to HTTPS works, but I believe there are advantages to using SSH instead.

SSH cloning worked for this repository in the first place (from a cygwin environment). Adding the host key within the Git Bash environment succeeded, however this has not fixed the issue for GitHub Desktop. I think we need to review how GitHub Desktop uses SSH to determine why it isn’t working. E.g., does it use ‘ssh.exe’ from its processes PATH?

iAmWillShepherd commented Apr 24, 2018

I believe there are advantages to using SSH instead.

Would you mind sharing these advantages and how using HTTPS does not fit into your workflow?

deed02392 commented Apr 26, 2018 •

@iAmWillShepherd I did not say that HTTPS does not fit into my workflow.

I was just of the understanding that SSH was more secure than HTTPS because it used keys instead of authenticating with my username and password on every connect. I also perhaps mistakenly have the impression that SSH generally performs git operations faster than HTTPS.

Using HTTPS will be merely a workaround anyway.

billygriffin commented Nov 29, 2018

I think this is a similar issue as #2085 so I’m going to close this. HTTPS should be a completely valid way to clone without any issues (I don’t think there’s a speed difference between the two but I could be mistaken), but we recognize that many people still prefer to use SSH so we’re tracking that as something to provide better support for in the future. Thanks!