This error occurs when your system cannot resolve the hostname (like github.com) to an IP address during an SSH connection. The issue is typically caused by DNS misconfiguration, network connectivity problems, or firewall restrictions blocking DNS queries.
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 [email protected]: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
First, verify that your network connection is working at all:
# Test if you can reach the internet (IP-based, no DNS needed)
ping -c 4 8.8.8.8If 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.
Check if DNS is working for any domain:
# Try to resolve github.com using system DNS
host github.com
# Or using nslookup
nslookup github.com
# Or using dig
dig github.comIf these fail, try using a specific DNS server to isolate the problem:
# Test with Google's DNS
host github.com 8.8.8.8
# Or with Cloudflare's DNS
nslookup github.com 1.1.1.1If the second set of commands works but the first doesn't, your system's DNS configuration needs to be fixed.
Check and update your DNS resolver configuration:
# View current DNS configuration
cat /etc/resolv.confIf it's empty or has incorrect entries, add public DNS servers:
# Edit resolv.conf (may need sudo)
sudo nano /etc/resolv.confAdd these lines:
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 1.1.1.1Save and test:
ping github.comNote: On systems using systemd-resolved or NetworkManager, changes to /etc/resolv.conf may be overwritten. See the next step for a permanent fix.
WSL often auto-generates /etc/resolv.conf with incorrect settings. To fix this permanently:
Step 1: Prevent auto-generation of resolv.conf
sudo nano /etc/wsl.confAdd these lines:
[network]
generateResolvConf = falseStep 2: Remove the auto-generated symlink and create a proper resolv.conf
# 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):
wsl --shutdownThen reopen your WSL terminal and test:
ping github.comSometimes IPv6 DNS or connectivity issues cause this error. You can force SSH to use IPv4:
Option 1: One-time fix via command line
git clone -c core.sshCommand="ssh -4" [email protected]:user/repo.gitOption 2: Configure SSH to always use IPv4 for GitHub
Edit or create ~/.ssh/config:
nano ~/.ssh/configAdd:
Host github.com
AddressFamily inet
Hostname github.com
User git
IdentityFile ~/.ssh/id_ed25519
Host *.github.com
AddressFamily inetOption 3: Set globally in Git config
git config --global core.sshCommand "ssh -4"Sometimes the DNS resolver service just needs a restart:
On Ubuntu/Debian with systemd-resolved:
sudo systemctl restart systemd-resolvedOn systems with NetworkManager:
sudo systemctl restart NetworkManager
# or
sudo service network-manager restartOn older systems:
sudo service networking restartFlush DNS cache (if using systemd-resolved):
sudo systemd-resolve --flush-caches
# or on newer systems
sudo resolvectl flush-cachesFirewalls or corporate proxies might be blocking DNS queries:
Check if DNS port is blocked:
# Try connecting to DNS server on port 53
nc -zv 8.8.8.8 53If 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:
# 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 cacheCheck proxy settings:
echo $http_proxy
echo $https_proxy
echo $no_proxyIf proxies are set, you might need to configure Git to use them:
git config --global http.proxy http://proxy.company.com:8080
git config --global https.proxy http://proxy.company.com:8080If SSH continues to have DNS issues, switching to HTTPS is a reliable alternative:
Change an existing remote:
# View current remote
git remote -v
# Change from SSH to HTTPS
git remote set-url origin https://github.com/username/repository.gitClone new repos using HTTPS:
# Instead of:
# git clone [email protected]:user/repo.git
# Use:
git clone https://github.com/user/repo.gitSet up credential storage for HTTPS:
# 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 wincredFor GitHub, you can also use a Personal Access Token (PAT) instead of password authentication.
If DNS is completely broken and you need an immediate workaround, you can manually add GitHub's IP:
Get GitHub's current IP addresses:
# From a machine where DNS works, or check GitHub's docs
dig github.com +shortAdd to /etc/hosts:
sudo nano /etc/hostsAdd a line like:
140.82.121.4 github.comImportant 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:
sudo nano /etc/hosts
# Remove the github.com line you addedUnderstanding 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:
# 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.comCorporate 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 - 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# docker-compose.yml
services:
app:
dns:
- 8.8.8.8
- 8.8.4.4For GitHub Actions and GitLab CI, DNS issues usually indicate runner network problems that may require runner reconfiguration or using a different runner.
kex_exchange_identification: Connection closed by remote host
Connection closed by remote host when connecting to Git server
fatal: unable to access: Proxy auto-configuration failed
How to fix 'Proxy auto-configuration failed' in Git
fatal: unable to access: Authentication failed (proxy requires basic auth)
How to fix 'Authentication failed (proxy requires basic auth)' in Git
fatal: unable to access: no_proxy configuration not working
How to fix 'no_proxy configuration not working' in Git
fatal: unable to read tree object in treeless clone
How to fix 'unable to read tree object in treeless clone' in Git