How to fix ssh: Could not resolve hostname github.com: Name or service not known in Git

GitBEGINNERMEDIUMUpdated May 28, 2026· 315 views

SSH can't resolve github.com to an IP, a DNS/network failure. Fix by correcting DNS resolvers, /etc/hosts, or your proxy.

Quick fix

Fixes ssh: Could not resolve hostname github.com: Name or service not known

# Test if you can reach the internet (IP-based, no DNS needed)
ping -c 4 8.8.8.8
  1. Test basic network connectivity
  2. Test DNS resolution directly
  3. Fix DNS configuration in /etc/resolv.conf
  4. Fix WSL-specific DNS issues (Windows Subsystem for Linux)
git — error
# Test if you can reach the internet (IP-based, no DNS needed)
ping -c 4 8.8.8.8
ssh: Could not resolve hostname github.com: Name or service not known

What this error means

The "ssh: Could not resolve hostname github.com: Name or service not known" error indicates that your system's DNS resolver cannot translate the hostname (github.com, gitlab.com, bitbucket.org, etc.) into an IP address. This is a network/DNS problem, not an SSH or Git configuration issue. When you run a Git command that uses SSH (like `git clone git@github.com:user/repo.git`), your system first needs to resolve the hostname to an IP address before establishing the SSH connection. If this DNS lookup fails, SSH cannot even begin to establish the connection, resulting in this error. This error commonly appears in several scenarios: - **WSL (Windows Subsystem for Linux)**: DNS configuration often breaks when switching networks or after system updates - **Virtual machines**: Especially when network adapters change or VPN connections are involved - **Corporate networks**: Firewalls or proxy servers may block or interfere with DNS queries - **Container environments**: Docker containers or CI/CD runners with misconfigured DNS - **After network changes**: Switching from WiFi to ethernet, or connecting/disconnecting from VPN

Typical symptoms

  • Git clone, push, pull, or fetch commands fail with hostname resolution error
  • Error message shows 'Name or service not known' or 'Temporary failure in name resolution'
  • SSH commands to any host fail with the same DNS error
  • The error occurs intermittently or only after network changes
  • ping github.com also fails with 'Name or service not known'
  • Commands work on the same machine in Windows but fail in WSL
  • CI/CD pipeline suddenly fails with DNS errors

Common causes

  1. DNS server is unreachable or not responding
  2. /etc/resolv.conf has incorrect or missing nameserver entries (especially common in WSL)
  3. Network connectivity issues preventing DNS queries
  4. Firewall blocking outbound DNS requests (port 53)
  5. VPN connection interfering with DNS resolution
  6. IPv6 DNS issues when IPv4 is expected or vice versa
  7. Corporate proxy requiring specific DNS configuration
  8. WSL resolv.conf being auto-generated with wrong settings
  9. Network manager or systemd-resolved service not running properly
  10. Temporary DNS server outage or rate limiting

How to fix "ssh: Could not resolve hostname github.com: Name or service not known"

1Test basic network connectivity

First, verify that your network connection is working at all:

bash
# Test if you can reach the internet (IP-based, no DNS needed)
ping -c 4 8.8.8.8

If this fails, you have a network connectivity issue, not just a DNS problem. Check:
- Is your WiFi/ethernet connected?
- Is your VPN connected (if required)?
- Are network cables properly plugged in?

If ping to 8.8.8.8 works, then the problem is specifically DNS resolution.

2Test DNS resolution directly

Check if DNS is working for any domain:

bash
# Try to resolve github.com using system DNS
host github.com

# Or using nslookup
nslookup github.com

# Or using dig
dig github.com

If these fail, try using a specific DNS server to isolate the problem:

bash
# Test with Google's DNS
host github.com 8.8.8.8

# Or with Cloudflare's DNS
nslookup github.com 1.1.1.1

If the second set of commands works but the first doesn't, your system's DNS configuration needs to be fixed.

3Fix DNS configuration in /etc/resolv.conf

Check and update your DNS resolver configuration:

bash
# View current DNS configuration
cat /etc/resolv.conf

If it's empty or has incorrect entries, add public DNS servers:

bash
# Edit resolv.conf (may need sudo)
sudo nano /etc/resolv.conf

Add these lines:

bash
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 1.1.1.1

Save and test:

bash
ping github.com

Note: On systems using systemd-resolved or NetworkManager, changes to /etc/resolv.conf may be overwritten. See the next step for a permanent fix.

4Fix WSL-specific DNS issues (Windows Subsystem for Linux)

WSL often auto-generates /etc/resolv.conf with incorrect settings. To fix this permanently:

Step 1: Prevent auto-generation of resolv.conf

bash
sudo nano /etc/wsl.conf

Add these lines:

ini
[network]
generateResolvConf = false

Step 2: Remove the auto-generated symlink and create a proper resolv.conf

bash
# Remove the symlink
sudo rm /etc/resolv.conf

# Create a new resolv.conf with public DNS
sudo bash -c 'echo "nameserver 8.8.8.8" > /etc/resolv.conf'
sudo bash -c 'echo "nameserver 1.1.1.1" >> /etc/resolv.conf'

Step 3: Restart WSL

In Windows PowerShell (as Administrator):

powershell
wsl --shutdown

Then reopen your WSL terminal and test:

bash
ping github.com
5Force IPv4 for SSH connections

Sometimes IPv6 DNS or connectivity issues cause this error. You can force SSH to use IPv4:

Option 1: One-time fix via command line

bash
git clone -c core.sshCommand="ssh -4" git@github.com:user/repo.git

Option 2: Configure SSH to always use IPv4 for GitHub

Edit or create ~/.ssh/config:

bash
nano ~/.ssh/config

Add:

bash
Host github.com
    AddressFamily inet
    Hostname github.com
    User git
    IdentityFile ~/.ssh/id_ed25519

Host *.github.com
    AddressFamily inet

Option 3: Set globally in Git config

bash
git config --global core.sshCommand "ssh -4"
6Restart network services

Sometimes the DNS resolver service just needs a restart:

On Ubuntu/Debian with systemd-resolved:

bash
sudo systemctl restart systemd-resolved

On systems with NetworkManager:

bash
sudo systemctl restart NetworkManager
# or
sudo service network-manager restart

On older systems:

bash
sudo service networking restart

Flush DNS cache (if using systemd-resolved):

bash
sudo systemd-resolve --flush-caches
# or on newer systems
sudo resolvectl flush-caches
7Check and fix firewall or proxy issues

Firewalls or corporate proxies might be blocking DNS queries:

Check if DNS port is blocked:

bash
# Try connecting to DNS server on port 53
nc -zv 8.8.8.8 53

If behind a corporate proxy, you may need to:

1. Use your company's internal DNS servers instead of public ones
2. Configure Git to use HTTPS instead of SSH:

bash
# Change remote from SSH to HTTPS
git remote set-url origin https://github.com/user/repo.git

# For authentication, set up credential caching
git config --global credential.helper cache

Check proxy settings:

bash
echo $http_proxy
echo $https_proxy
echo $no_proxy

If proxies are set, you might need to configure Git to use them:

bash
git config --global http.proxy http://proxy.company.com:8080
git config --global https.proxy http://proxy.company.com:8080
8Switch to HTTPS as a workaround

If SSH continues to have DNS issues, switching to HTTPS is a reliable alternative:

Change an existing remote:

bash
# View current remote
git remote -v

# Change from SSH to HTTPS
git remote set-url origin https://github.com/username/repository.git

Clone new repos using HTTPS:

bash
# Instead of:
# git clone git@github.com:user/repo.git

# Use:
git clone https://github.com/user/repo.git

Set up credential storage for HTTPS:

bash
# Cache credentials for 1 hour
git config --global credential.helper 'cache --timeout=3600'

# Or store permanently (less secure)
git config --global credential.helper store

# On macOS, use Keychain
git config --global credential.helper osxkeychain

# On Windows, use Windows Credential Manager
git config --global credential.helper wincred

For GitHub, you can also use a Personal Access Token (PAT) instead of password authentication.

9Add GitHub's IP to /etc/hosts as a last resort

If DNS is completely broken and you need an immediate workaround, you can manually add GitHub's IP:

Get GitHub's current IP addresses:

bash
# From a machine where DNS works, or check GitHub's docs
dig github.com +short

Add to /etc/hosts:

bash
sudo nano /etc/hosts

Add a line like:

bash
140.82.121.4 github.com

Important warnings:
- This is a temporary workaround, not a permanent fix
- GitHub's IP addresses can change
- This won't work for GitHub subdomains (like raw.githubusercontent.com)
- Fix your actual DNS configuration as soon as possible

To remove later:

bash
sudo nano /etc/hosts
# Remove the github.com line you added

Advanced notes

Understanding DNS resolution in Linux:

When your system needs to resolve a hostname, it typically follows this order (defined in /etc/nsswitch.conf):

1. /etc/hosts - Local hostname mappings
2. DNS servers - Listed in /etc/resolv.conf or managed by systemd-resolved

On modern systems, systemd-resolved manages DNS with a local caching resolver at 127.0.0.53. The actual DNS servers it uses come from NetworkManager, DHCP, or static configuration.

WSL DNS architecture:

WSL 2 runs in a lightweight VM and has its own networking stack. By default, Windows generates /etc/resolv.conf pointing to the Windows host's DNS. This can break when:

- Windows DNS settings change
- VPN connects/disconnects
- Network adapters change
- Windows Firewall blocks WSL's DNS traffic

The generateResolvConf = false setting in /etc/wsl.conf prevents this auto-generation, letting you maintain a static DNS configuration.

Debugging DNS issues:

Use these commands to diagnose DNS problems:

bash
# Check systemd-resolved status
systemd-resolve --status

# See which DNS servers are being used
resolvectl status

# Test specific DNS server
dig @8.8.8.8 github.com

# Check if it's an IPv6 issue
dig AAAA github.com  # IPv6 lookup
dig A github.com     # IPv4 lookup

# Verbose DNS query
dig +trace github.com

Corporate network considerations:

Many corporate networks use internal DNS servers that may:

- Block external DNS queries (8.8.8.8, 1.1.1.1)
- Require VPN connection for internal resources
- Use DNS for access control (blocking certain domains)
- Implement split-DNS (different resolution for internal vs external)

In these environments, you typically need to:
1. Use the company-provided DNS servers
2. Connect to VPN when required
3. Use HTTPS with proxy settings instead of SSH

CI/CD and container DNS:

In Docker containers and CI/CD environments:

dockerfile
# Dockerfile - set DNS in container
RUN echo "nameserver 8.8.8.8" > /etc/resolv.conf

# Or use Docker's --dns flag
# docker run --dns 8.8.8.8 myimage
yaml
# docker-compose.yml
services:
  app:
    dns:
      - 8.8.8.8
      - 8.8.4.4

For GitHub Actions and GitLab CI, DNS issues usually indicate runner network problems that may require runner reconfiguration or using a different runner.

Frequently asked questions

What does "ssh: Could not resolve hostname github.com: Name or service not known" mean?
) into an IP address. This is a network/DNS problem, not an SSH or Git configuration issue. git), your system first needs to resolve the hostname to an IP address before establishing the SSH connection.
How do I fix "ssh: Could not resolve hostname github.com: Name or service not known"?
SSH can't resolve github.com to an IP, a DNS/network failure. Fix by correcting DNS resolvers, /etc/hosts, or your proxy.
What causes "ssh: Could not resolve hostname github.com: Name or service not known"?
DNS server is unreachable or not responding /etc/resolv.conf has incorrect or missing nameserver entries (especially common in WSL) Network connectivity issues preventing DNS queries
Is the "ssh: Could not resolve hostname github.com: Name or service not known" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading