516

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://username@domain.example/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.

Stephen Ostermiller
  • 23,933
  • 14
  • 88
  • 109
bootsz
  • 5,271
  • 3
  • 13
  • 4
  • 20
    You **are** using SSH to connect to this repository, notice how your URL begins with `ssh://` – Brandon Jan 09 '19 at 22:16
  • 15
    NOTE: GitHub just reset their host key. They have a separate solution in their blog post. See https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/ – Ryan Shillington Mar 26 '23 at 05:01
  • I followed the instructions in the blog above (using edit known hosts file), and git synced yesterday, but today I get "Host key verification failed...". The fix in the blog is meant to be a persistent solution, correct? – Frank_Coumans Mar 30 '23 at 07:56

33 Answers33

865

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
Boris Verkhovskiy
  • 14,854
  • 11
  • 100
  • 103
Tupy
  • 11,663
  • 4
  • 18
  • 11
  • 4
    This is the most secure way, short of already having the key present. That's assuming you only run it once, not every time you connect to the server. – Zenexer Aug 13 '15 at 13:49
  • My company's private fit repository is using ecdsa as key, so if the solution isn't working, maybe it is because the algorithm isn't correct – Fendy Apr 12 '16 at 03:07
  • 2
    worked for me too, I was wondering why I couldn't clone my own repo – StackAttack Nov 16 '18 at 16:34
  • Somebody has flagged this post (incorrectly). [From Review](https://stackoverflow.com/review/low-quality-posts/22279187). – Wai Ha Lee Feb 22 '19 at 12:04
  • FYI, your post has been flagged as low quality and the flag has been declined. [From Review](https://stackoverflow.com/review/low-quality-posts/22279187) – double-beep Feb 22 '19 at 12:12
  • 12
    If you're using Windows, the easiest is to install git-for-windows(download) and open Git Bash . Inside this console you can use the ssh-keyscan command – Rafael Araújo Mar 25 '19 at 14:51
  • 3
    You don't know how many years of frustration your answer could save. It also fixed the authentication errors of github desktop. I need to try it with my flu as well XD – Diaa Jul 25 '21 at 02:18
  • First day at a new job on a new MacBook, you just saved me from a build issue my senior dev had never seen before. Cheers m8 – JMA Dec 13 '21 at 21:19
  • Before adding the keys directly to a `known_hosts` file, you should probably compare [the key fingerprints](https://unix.stackexchange.com/questions/126908/get-ssh-server-key-fingerprint) to fingerprints provided via [another 'channel'](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints). – Kenny Evitt Jan 15 '22 at 22:04
  • Please note that `mkdir -p ~/.ssh` may be necessary first, as noted in @Saran's answer. – TrueWill Mar 29 '22 at 14:46
  • For windows: ssh-keyscan -t rsa github.com > %USERPROFILE%/.ssh/known_hosts – Jimmie Clark Feb 17 '23 at 16:16
323

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.

Stephen Ostermiller
  • 23,933
  • 14
  • 88
  • 109
Greg Bacon
  • 134,834
  • 32
  • 188
  • 245
  • 8
    Fun fact, running `sudo ssh-keygen -R domain.com` can rename your existing `known_hosts` file to be `known_hosts.old`, and create a copy _that is only readable by root_. (`-rw------- root root`) You can easily `chown` this back to the appropriate user, but you also might waste an afternoon debugging why git is broken. :D – Andrew Rueckert Feb 28 '20 at 23:39
  • 30
    `Are you sure you want to continue connecting (yes/no)?`. Don't make the same mistake as me. You need to type `yes`. Simply hitting enter doesn't select yes by default – JolonB May 24 '20 at 22:20
  • In my case, I simply hadn't mounted the existing `known_hosts` file into the container. In addition to mounting my SSH key into the container, I added `-v ${HOME}/.ssh/known_hosts:/root/.ssh/known_hosts` to my `docker run` command. – Cameron Hudson Aug 19 '20 at 17:40
  • 3
    For CI environments, like Jenkins, you can not asnwer yes when prompted to. So, make sure that: 1. you have the ssh keys correctly created and in the .ssh dir inside your home. 2. the target domain added to known_hosts as stated here. – Sebastian Juarez Aug 25 '20 at 19:47
  • 4
    One gotcha is that you might need the port number for the remote repository: `ssh-keyscan -p 8888 -t rsa domain.com >> ~/.ssh/known_hosts` – andrew Apr 15 '21 at 23:53
  • 7
    @AndrewRueckert one of the many reasons why randomly adding `sudo` to the beginning of commands is a bad idea. – jbg Apr 19 '21 at 12:00
  • Note that you might have more than one entry for github in the known_hosts file. In my case, I had github.com and 140.82.121.3 which also points to github.com apparently, but had the wrong RSA key. I had to merge both into a single entry to fix it. `github.com,140.82.121.3 ssh-rsa ` – Khalibloo Mar 24 '23 at 10:48
  • 2
    @AndrewRueckert man you have no idea how much this helped me, a dockerfile I was working with was doing manipulations on known_hosts while using root user, and that was causing all sorts of troubles. Thanks! – ivanibash Mar 31 '23 at 13:21
  • Also I would not bother adding it "by hand" using `keyscan`. E.g. it's easy to add the wrong key, forget subdomains, etc. Using a simple git fetch and 'yes' takes care of all of that for you. Also if your known_hosts seems f'ed up / has more entries than needed, just wipe its contents first. – laka Aug 23 '23 at 07:59
101

I had the similar issue, but, using SSH keys. From Tupy's answer, above, I figured out that the issue is with known_hosts file not being present or github.com not being present in the list of known hosts. Here are the steps I followed to resolve it -

  1. mkdir -p ~/.ssh
  2. ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts
  3. ssh-keygen -t rsa -C "user.email"
  4. open the public key with this command $ cat ~/.ssh/id_rsa.pub and copy it.
  5. Add the id_rsa.pub key to SSH keys list on your GitHub profile.
Saran
  • 1,253
  • 1
  • 9
  • 10
  • 2
    @OJFord FYI: I have edited the original answer in a way that makes your comment obsolete. TBH and with all due respect it wasn't entirely correct in the first place. The `touch` command would fail in case `~/.ssh` directory does not exist, so step 1 was still required. Also you don't need to `touch` the file before using `>>` redirection. It will be created if necessary (but just the file, not entire path, so still `mkdir -p` is needed). The `-p` option make it work in case the directory already exists. – Tad Lispy Jun 10 '18 at 17:14
  • 2
    It's the #2 `ssh-keyscan` that's missing from the Github docs on adding a new ssh key. – Max Phillips Oct 14 '19 at 15:03
  • 2
    I was having issues with my `Dockerfile` having a lack of permission. Adding the 2nd step here fixed that problem! Thank you for the great work – Spencer Pollock Feb 16 '20 at 09:56
  • I followed the above step and failed as I was giving github.com as the hostKey in spring config server properties files. Those who are failing to connect spring.cloud.config-server to fetch from git, see this https://tranhoangminh.wordpress.com/2018/09/14/spring-cloud-config-server-and-ssh-git-repository/. Well explained here. – SHAKU Mar 20 '21 at 17:42
78

This is happening because github is not currently in your known hosts.

You should be prompted to add github to your known hosts. If this hasn't happened, you can run ssh -T git@github.com to receive the prompt again.

Powderham
  • 1,510
  • 12
  • 14
38

For me, I just had to type "yes" at the prompt which asks "Are you sure you want to continue connecting (yes/no)?" rather than just pressing Enter.

Code-Apprentice
  • 81,660
  • 23
  • 145
  • 268
  • 2
    This answer lead me to realize I had to manually clone my repo on my build server in order to type 'yes' and get my bitbucket server added to my known_hosts – Sashah Nov 20 '17 at 20:34
  • 2
    @Sashah If all you need is the bitbucket server in known_hosts, you can edit the file manually. No need to clone the repo if this is the only reason to do so. – Code-Apprentice Dec 13 '17 at 16:03
  • 2
    Wow, I was stuck on this for the past hour and this solved it. Thank you! – Akanksha Atrey Jun 02 '22 at 16:58
18

When the terminal shows:

Are you sure you want to continue connecting (yes/no)?

DO NOT I repeat DO NOT directly pressed Enter.

You MUST TYPE yes first in the terminal, then press Enter.

Muhammad Fauzi Masykur
  • 1,994
  • 1
  • 15
  • 18
17

If you are in office intranet (otherwise dangerous) which is always protected by firewalls simply have the following lines in your ~/.ssh/config.

Host *
  StrictHostKeyChecking no
  UserKnownHostsFile=/dev/null
kenorb
  • 155,785
  • 88
  • 678
  • 743
sunil
  • 491
  • 4
  • 10
  • 7
    This is still dangerous, with our without corporate firewalls. How do you know you're talking to the real github without verifying the server key? – Mnebuerquo Mar 17 '18 at 20:42
  • 2
    In corporate environments local git repos are mostly used, never opensource one. Worst case .ssh config at the top of the file can have github explicit host related config lines for ssh to choose more specific matches. – sunil May 21 '18 at 13:36
14

When asked:

Are you sure you want to continue connecting (yes/no)?

Type yes as the response

That is how I solved my issue. But if you try to just hit the enter button, it won't work!

Victor Bruce
  • 217
  • 2
  • 11
10

I got the same problem on a newly installed system, but this was a udev problem. There was no /dev/tty node, so I had to do:

mknod -m 666 /dev/tty c 5 0
Jaffa
  • 12,442
  • 4
  • 49
  • 101
  • 2
    It worked for me because /dev/tty was created as a file, very odd! (so you have to remove it then recreate it with mknod) – Doomsday Nov 02 '14 at 14:31
  • @Geoffroy , I removed /dev/tty and now when do sudo , I face this error : sudo: sorry, you must have a tty to run sudo – Milad Dec 17 '14 at 12:29
  • @xe4me I never said you should remove it, depending on the system it is actually required. Reboot should fix it. – Jaffa Dec 17 '14 at 17:33
  • @Geoffroy , actually the first commentator , said I have to remove and the recreate :d Nope , rebooting didn't work , I had to tell the root , he fixed it :d – Milad Dec 18 '14 at 09:58
7

What worked for me was to first add my SSH key of the new computer, I followed these instructions from GitLab - add SSH key. Note that since I'm on Win10, I had to do all these commands in Git Bash on Windows (it didn't work in regular DOS cmd Shell).

Then again in Git Bash, I had to do a git clone of the repo that I had problems with, and in my case I had to clone it to a different name since I already had it locally and didn't want to lose my commits. For example

git clone ssh://git@gitServerUrl/myRepo.git myRepo2

Then I got the prompt to add it to known hosts list, the question might be this one:

Are you sure you want to continue connecting (yes/no)?

I typed "yes" and it finally worked, you should typically get a message similar to this:

Warning: Permanently added '[your repo link]' (ECDSA) to the list of known hosts.

Note: if you are on Windows, make sure that you use Git Bash for all the commands, this did not work in regular cmd shell or powershell, I really had to do this in Git Bash.

Lastly I deleted the second clone repo (myRepo2 in the example) and went back to my first repo and I could finally do all the Git stuff like normal in my favorite editor VSCode.

ghiscoding
  • 12,308
  • 6
  • 69
  • 112
6

When the remote server wants to connect to the private repo, it would authenticate via ssh. Create the private-public key pair with ssh-keygen or if you already have the public-private key. copy&paste the public key in the Settings of the private repo.

YourPrivateRepo -> Settings -> Deploy Keys -> Add deploy key -> Paste the public key.

Now the remote server would be able to connect to the private repo.

NOTE: The deploy keys has access only for reading the repo. Need to explicitly allow write access.

Sandy
  • 946
  • 11
  • 14
5

If you are using git for Windows.

  • Open the git GUI.
  • Open the local git repository in git GUI.
  • Add the remote or push if the remote already exists.
  • Answer "yes" to the question about whether you want to continue.

The GUI client adds the key for you to ~/.ssh/known_hosts. This is easier to remember if you don't do it often and also avoids the need to use the git command line (the standard Windows command lines don't have the ssh-keyscan executable.

Julian Knight
  • 4,716
  • 2
  • 29
  • 42
4

The solutions mentioned here are great, the only missing point is, what if your public and private key file names are different than the default ones?

Create a file called "config" under ~/.ssh and add the following contents

Host github.com
    IdentityFile ~/.ssh/github_id_rsa

Replace github_id_rsa with your private key file.

RP-
  • 5,827
  • 2
  • 27
  • 46
3

You can use your "git url" in 'https" URL format in the Jenkinsfile or wherever you want.

git url: 'https://github.com/jglick/simple-maven-project-with-tests.git'

Nitin
  • 10,101
  • 4
  • 17
  • 34
3

I was facing the same error inside DockerFile during build time while the image was public. I did little modification in Dockerfile.

 RUN git clone  https://github.com/kacole2/express-node-mongo-skeleton.git /www/nodejs

This would be because using the git@github.com:... syntax ends up > using SSH to clone, and inside the container, your private key is not > available. You'll want to use RUN git clone > https://github.com/edenhill/librdkafka.git instead.

Adiii
  • 54,482
  • 7
  • 145
  • 148
3

You kan use https instead of ssh for git clone or git pull or git push

ex:

git clone https://github.com/user/repo.git
Lamri Djamal
  • 236
  • 1
  • 10
3

One small addition to Tupy's answer, you may need to add the port number for your repository host:

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

If you have another machine that does have remote access you can find the port number by viewing ~/.ssh/known_hosts:

[user]$ less ~/.ssh/known_hosts
[domain.example]:8888,[000.00.000.000]:8888 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCi...
Stephen Ostermiller
  • 23,933
  • 14
  • 88
  • 109
andrew
  • 3,929
  • 1
  • 25
  • 38
3

Check permissions on the known_hosts file as well - both the user's (~/.ssh/known_hosts) and the global one (/etc/ssh/ssh_known_hosts).

In my case the old host was in /etc/ssh/ssh_known_hosts. When I removed it as root with sudo ssh-keygen -f /etc/ssh/ssh_known_hosts -R THE_HOST it changed permissions on that file to 0600, so SSHing to THE_HOST as root worked, but for any other user it failed with "Host key verification failed". The fix was:

sudo chmod 644 /etc/ssh/ssh_known_hosts
EM0
  • 5,369
  • 7
  • 51
  • 85
3

Dashboard > Manage Jenkins > Configure Global Security > Git Host Key Verification Configuration. Then in Host Key Verification Strategy select Accept first connection.

Abd Abughazaleh
  • 4,615
  • 3
  • 44
  • 53
2

Its means your remote host key was changed (May be host password change),

Your terminal suggested to execute this command as root user

$ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net]

You have to remove that host name from hosts list on your pc/server. Copy that suggested command and execute as a root user.

$ sudo su                                                        // Login as a root user

$ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net]    // Terminal suggested command execute here
Host [www.website.net]:4231 found: line 16 type ECDSA
/root/.ssh/known_hosts updated.
Original contents retained as /root/.ssh/known_hosts.old

$ exit                                                           // Exist from root user

Try Again, Hope this works.

Jaykumar Patel
  • 26,836
  • 12
  • 74
  • 76
  • Note: depending on your shell, you may have to escape the square brackets \\[ and \\] or use quotes. – Phlarx Jan 16 '17 at 19:38
2

Reason seems to be that the public key of the remote host is not stored or different from the stored one. (Be aware of security issues, see Greg Bacon's answer for details.)

I was used to git clone prompting me in this case:

The authenticity of host 'host.net (10.0.0.42)' can't be established.
ECDSA key fingerprint is 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00.
Are you sure you want to continue connecting (yes/no)?

Not sure, why this error is thrown instead. Could be the configuration of your shell or the git SSH command.
Anyhow, you can get the same prompt by running ssh user@host.net.

2

A other alternative worked for me, instead of cloning the SSH link

git@gitlab.company.net:upendra/mycode.git

there is a option to select http link

http://gitlab.company.net:8888/upendra/mycode.git

So I used http link to clone for Visual studio and it worked for me

u_pendra
  • 908
  • 1
  • 10
  • 25
2

If you are not using a Windows Session to update the code, and you use PortableGit, you need to set the HOMEPATH environment variable before running the git command.

This example fits better for other use case, but I think it is a good of proof-of-concept for this post.

$env:HOMEPATH="\Users\Administrator";C:\path\to\PortableGit\bin\git.exe -C C:\path\to\repository.git pull'

Tk421
  • 6,196
  • 6
  • 38
  • 47
2

Pushing to Git returning Error Code 403 fatal: HTTP request failed

Check if there is Billing issue. Google Cloud stops uploading files to https://source.cloud.google.com/

I got this problem went away after Payment issue was fixed. But did not change the Keys.

Thanks

K D
  • 205
  • 3
  • 10
2

I just cleared out my known host file and that seemed to do the trick.

Daniel L. VanDenBosch
  • 2,350
  • 4
  • 35
  • 60
  • if anyone is wondering why this could be a solution, when the remote repository changes its ssh public key (but you still have the old one stored under .ssh\known_hosts) - emptying known_hosts file content will trigger to store the new key in your known_hosts. – LeTex May 24 '23 at 22:17
0

Alternatively, if you're using MSYS2 terminals (on Windows*) and a passphrase, it might be that the terminal does not prompt the 'Enter passphrase' properly, thus denying access to SSH.

If you're on Windows, you can instead use the Git Bash or Powershell to get the prompt and properly connect. (I'm currently looking for a solution for MSYS.)

*Not sure if relevant.

Prometheos II
  • 334
  • 3
  • 14
0

Problem: Host key verification failed. fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists.

Solution: I've checked all the settings and also checked the key settings in GitHub. Finally, I changed the Git URL from "git@github.com:palvsv/travelo-moon.git" to "https://github.com/palvsv/travelo-moon.git" in .config file "yourprojectdirectory/.git/config" and it works.

  • 2
    I also had to do this, thank you! – jamie Nov 16 '21 at 19:57
  • 2
    This worked for me!, thank you @TRUPAL – Navin Leon Jan 11 '22 at 18:54
  • 2
    This simply changes the authentication method from SSH to HTTPS - this is not a solution if you're actually trying to use SSH keys, which the OP was not, however a bunch of other people here are, so I would say this isn't extremely valid for 90% of use cases. – Arcsector Feb 09 '22 at 22:58
-1

For a newbie, you will need to log in to Jenkins using the following command before performing the aforementioned actions:

sudo su - jenkins

This worked for me.

-2

for me, I just rename the "known_hosts" file to "known_hosts.del" for backup. and then rerun git clone xxx and type "yes". I will create new "known_hosts"

li bo
  • 1
  • 3
    There are **26 existing answers** to this question, including a top-voted, accepted answer with over **five hundred votes**. Are you _certain_ your solution hasn't already been given? If not, why do you believe your approach improves upon the existing proposals, which have been validated by the community? Offering an explanation is _always_ useful on Stack Overflow, but it's _especially_ important where the question has been resolved to the satisfaction of both the OP and the community. Help readers out by explaining what your answer does different and when it might be preferred. – Jeremy Caney Jan 28 '22 at 00:55
  • This is not a good solution because it removes all the /good/ lines in the file as well the problematic one. This treats every host in the file as untrusted again. – Mark Stosberg May 17 '23 at 14:04
-2

Just type 'yes' and press enter this should work

CsAlkemy
  • 152
  • 1
  • 6
-2

remove package-lock.json or yarn.lock and then try again

  • In your auto stop, please, remove theirs tires and then try again – abkrim Aug 02 '23 at 04:07
  • This is not the solution. The error message is caused by ssh being unable to reach the server. It doesn't have to do with the contents of the repository itself. – cassi.lup Aug 18 '23 at 07:27
-3

I had the similar issue, unfortunately I used the GitExtensions HMI and forgot that I wrote a passphrase. With HMI.... forget it ! Do not enter passphrase when you generate your key !

Jerome Vacher
  • 314
  • 1
  • 7
-6

I got this message when I tried to git clone a repo that was not mine. The fix was to fork and then clone.

fyodrs
  • 1
  • 1