ssh: Could not resolve hostname git: Name or service not known fatal: Could not read from remote repository

Viewed 148626

After I switched from HTTPS to SSH for my repo then I received this error when pushing to origin master:

ssh: Could not resolve hostname git: Name or service not known
fatal: Could not read from remote repository.

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

I also add my ssh in the gitlab. What should I do?

9 Answers

I was getting the same error.

Change the [remote "origin"] url value in .gitconfig or .config/git/config file

Previously:

https://git@github.com:userName/repo.git

OR

ssh://git@github.com:userName/repo.git

New:

git@github.com:userName/repo.git

HTTPS URLs provides an easy access to your repository, either private or public, even when you are working behind a firewall or proxy. And it is the recommended way.

On the other hand, SSH URLs use the secure ssh protocol in order to access a repository.

Coming back to your question, the error is likely because of improper configuration. The git remote add command is used to add a new remote to your repository, that you have already tried. However, switching from HTTPS to SSH url, means that your remote origin is already set to an http url and that you want to change.

Therefore, first check what url your current remote origin is referring to:

$ git remote -v

If it is referring to the HTTPS url, then you have to use

$ git remote set-url origin mySSH_url

command to change it to the SSH url.

Now, try git remote -v, it would display SSH urls configured for origin.

Do make sure that while working with SSH urls, you have generated and added the ssh key to the ssh-agent as well on GitLab/GitHub account.

Here is a very good article on how to change a remote's url.

Also, you can learn more about which remote url to use here.

Well, in my case my local system was not connected to the VPN and hence was getting this error. So this could be one of the reasons apart from the above answers.

I faced the same issue when working on azure.

ssh: Could not resolve hostname ssh.abc.azure.com: Temporary failure in name 
resolution
fatal: Could not read from remote repository.

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

Reason: This issue is due to the failure in WSL2.

Fix: Disable and enable the WSL.

For me it was a simple solution to a "dumb" problem:

After typing $ git push, I was prompted Are you sure you want to continue connecting (yes/no)?, and instead of just hitting enter, actually writing "yes" and then hitting enter solved it!

While all the answers address the possibility of authentication failing with gitlab, the problem could also be DNS on your local system. For example:

$ ssh -Tvvv git@gitlab.com
debug2: resolving "gitlab.com" port 22
ssh: Could not resolve hostname gitlab.com: Name or service not known
$ ping gitlab.com
$ ping: gitlab.com: Name or service not known

This shows an issue with DNS settings on your computer. In RedHat, try this:

systemctl status NetworkManager
dnsmasq[2328]: nameserver 192.168.100.1 refused to do a recursive query

Oh my, that's a problem.

Is your network connection up?

$ ip a s
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 28:cd:c4:80:b8:0b brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.7/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp2s0
       valid_lft 86127sec preferred_lft 86127sec
    inet6 fe80::dd85:ef7b:1632:5975/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

$ ip route
default via 192.168.1.1 dev wlp2s0 proto dhcp metric 600 

$ ip link
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether 28:cd:c4:80:b8:0b brd ff:ff:ff:ff:ff:ff

For me, yes. Try restarting the connection:

$ sudo ip link set dev wlp2s0 down
$ sudo ip link set dev wlp2s0 up

Now try running:

sudo systemctl status NetworkManager

And if the previous error went away, you can now ping gitlab.com.

git push -u origin master

I also found this error because I used backslashes "\" in the URL instead of slashes "/".

I also had the same problem when I was using git push -u origin branchA, but when I used the one recommend on bash git push --set-upstream origin branchA it worked out fine.

Answer for when you have upgraded from WSL version 1 to version 2.

For some reason github.com can't be resolved once that update happens. The issue has been raised against this ticket, there are also several solutions provided. The once that worked for me are: https://github.com/microsoft/WSL/issues/4285#issuecomment-522201021 https://github.com/microsoft/WSL/issues/4285#issuecomment-532962762 -> modified version of the first solution

At step 3 you are asked to write to file /etc/resolv.conf which was tricky since it was a symbolic link. Following these steps resolved the writing problem

Related