How to fix ssh: Could not resolve hostname hostname: Name or service not known in SSH

SSHINTERMEDIATEMEDIUMUpdated Jan 4, 2026· 322 views

SSH cannot translate the hostname to an IP address due to DNS resolution failures, incorrect hostname spelling, network connectivity issues, or misconfigured DNS settings. Fix by verifying hostname spelling, checking DNS resolution, updating /etc/hosts, or using the IP address directly.

Quick fix

Fixes ssh: Could not resolve hostname hostname: Name or service not known

ssh myserver:22           # Incorrect - port syntax wrong
ssh user myserver         # Incorrect - missing @ symbol
  1. Verify the hostname spelling and SSH command syntax
  2. Test DNS resolution using ping or nslookup
  3. Check your system's DNS configuration
  4. Try connecting using the IP address instead
ssh — error
ssh myserver:22           # Incorrect - port syntax wrong
ssh user myserver         # Incorrect - missing @ symbol
ssh: Could not resolve hostname hostname: Name or service not known

What this error means

This error occurs when the SSH client attempts to connect to a remote server but cannot resolve the hostname to an IP address. The system's DNS resolver (or local hosts file) is unable to translate the hostname you provided into a valid IP address. This can happen due to DNS server unavailability, incorrect hostname, network connectivity problems, or misconfigured DNS settings on your local machine. SSH requires a valid hostname or IP address to establish a connection, so resolution failure blocks the connection attempt before any authentication even occurs.

Typical symptoms

  • SSH connection fails with 'Could not resolve hostname' message
  • Hostname cannot be pinged or resolved using nslookup/dig
  • The same hostname works from other machines but not from your current system
  • SSH works fine when using the IP address instead of hostname
  • Recently added hostname to /etc/hosts is still not resolvable
  • VPN connection was recently disconnected or changed

Common causes

  1. Typo or misspelling in the hostname you're trying to connect to
  2. DNS servers are unreachable or not responding to queries
  3. Hostname does not exist in DNS or is not properly registered
  4. Local /etc/hosts file is missing the hostname-to-IP mapping
  5. Incorrect hostname in SSH client configuration file (~/.ssh/config)
  6. Network connectivity issues preventing DNS queries
  7. Firewall blocking port 53 (DNS) traffic
  8. Hostname is only resolvable on internal corporate DNS, not public DNS
  9. /etc/resolv.conf is misconfigured or pointing to invalid DNS servers
  10. SSH command syntax error (e.g., wrong user@hostname format)

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

1Verify the hostname spelling and SSH command syntax

Check that you typed the hostname correctly and are using proper SSH syntax. SSH expects the format ssh user@hostname or ssh hostname if no user is specified.

Wrong format:

bash
ssh myserver:22           # Incorrect - port syntax wrong
ssh user myserver         # Incorrect - missing @ symbol

Correct format:

bash
ssh user@myserver         # Correct
ssh -p 2222 user@myserver # Correct with custom port
ssh myserver              # Correct if user defaults apply

Common typos to watch for:
- sever instead of server
- localhost misspelled
- Domain name missing (e.g., myhost when it should be myhost.example.com)

2Test DNS resolution using ping or nslookup

Use the ping command to verify the hostname resolves to an IP address:

bash
ping hostname
ping example.com

If ping fails with "unknown host" or similar, DNS resolution is broken. Test with nslookup or dig for more details:

bash
nslookup hostname          # Query DNS for hostname
dig hostname               # Detailed DNS query
dig hostname +short        # Show just the IP

If these commands also fail, your DNS configuration is the issue. If they succeed but SSH still fails, see the next steps.

3Check your system's DNS configuration

View your current DNS servers in /etc/resolv.conf:

bash
cat /etc/resolv.conf

Look for lines starting with nameserver. Common valid values are:
- nameserver 8.8.8.8 (Google DNS)
- nameserver 1.1.1.1 (Cloudflare DNS)
- Your ISP's DNS servers

If the file is empty or missing nameserver entries, DNS will fail. On systems using systemd-resolved (Ubuntu 18.04+, Fedora, etc.), instead check:

bash
systemd-resolve --status

If DNS servers are missing or invalid, you can temporarily set Google DNS:

bash
sudo nano /etc/resolv.conf
# Add or modify:
nameserver 8.8.8.8
nameserver 8.8.4.4

On modern systems with NetworkManager or systemd-resolved, this change may not persist. See your distribution's documentation for permanent DNS configuration.

4Try connecting using the IP address instead

If you know the server's IP address, connect directly to bypass DNS:

bash
ssh user@192.168.1.100
ssh user@74.6.11.164

If this succeeds, the problem is definitely DNS-related and not a network or firewall issue. This confirms the hostname itself is the problem, not the connection.

5Add hostname to /etc/hosts for local resolution

Edit the /etc/hosts file to manually map the hostname to its IP address. This bypasses DNS for that specific hostname:

bash
sudo nano /etc/hosts

Add a line in the format IP_ADDRESS hostname:

bash
127.0.0.1       localhost
::1             localhost
192.168.1.100   myserver
192.168.1.101   myserver.local
74.6.11.164     example.com

Save (Ctrl+X, then Y, then Enter in nano). Then test:

bash
ping myserver
ssh user@myserver

The /etc/hosts file is checked before DNS queries, so this provides an instant resolution. Use this for frequently-accessed private servers or temporary workarounds while DNS issues are being investigated.

6Review your SSH config file for typos

If you're using SSH host aliases in ~/.ssh/config, check for misconfigurations:

bash
nano ~/.ssh/config

Look for incorrect HostName entries or duplicate host definitions:

bash
Host myserver
    HostName myserver.example.com    # Make sure this is correct
    User ubuntu
    Port 22

Host production
    HostName 192.168.1.100           # Can use IP or hostname
    User admin
    IdentityFile ~/.ssh/id_ed25519

Common issues:
- Typo in HostName value
- Space issues around the = (use spaces, not =)
- Indentation matters (options must be indented under Host)

After editing, test:

bash
ssh myserver    # Uses alias from config
7Check /etc/nsswitch.conf host resolution order (Linux only)

On Linux systems, the /etc/nsswitch.conf file controls the order in which the system searches for hostnames. Check the hosts: line:

bash
cat /etc/nsswitch.conf | grep hosts

Typical output:

bash
hosts: files dns myhostname

This means:
1. Check /etc/hosts first (files)
2. Then query DNS servers (dns)
3. Then use systemd hostname resolution (myhostname)

If the order is wrong or dns is missing, hostname resolution may fail. The recommended order is:

bash
hosts: files dns

To fix, edit it:

bash
sudo nano /etc/nsswitch.conf

Change the hosts line if needed and save.

8Verify network connectivity and firewall rules

Ensure your machine can reach external networks and DNS servers:

bash
# Check if you have internet connectivity
ping 8.8.8.8

# Check if you can reach the target server (if IP is known)
ping 192.168.1.100
traceroute 192.168.1.100

# Check if DNS port 53 is accessible
telnet 8.8.8.8 53
nc -zv 8.8.8.8 53

If pings to 8.8.8.8 fail, check:
- Network interface status: ip link show or ifconfig
- Routes: ip route show or route -n
- WiFi/Ethernet connection status

If you're behind a corporate firewall or proxy:
- Firewall may be blocking DNS (port 53) or SSH (port 22)
- Contact your network administrator
- May need to configure a proxy in SSH: add ProxyCommand to ~/.ssh/config

Check firewall rules on your local machine:

bash
# Ubuntu/Debian
sudo ufw status

# Fedora/RHEL
sudo firewall-cmd --list-all

Advanced notes

DNS Caching Issues: Some systems cache DNS results. If you recently changed DNS servers or updated /etc/hosts, the old result may be cached. Clear the cache with: sudo systemctl restart systemd-resolved (systemd systems) or sudo dscacheutil -flushcache (macOS). Corporate/Internal DNS: Private hostnames (e.g., internal.company.com) may only resolve on corporate DNS servers, not public DNS. Ensure your system is on the corporate network or VPN. Hostname vs FQDN: SSH prefers fully-qualified domain names (FQDN) like server.example.com over short names like server. Some networks only resolve FQDNs. Multiple Network Interfaces: If your system has multiple network cards or is in a complex network setup, the DNS server for one interface may differ from another. Check all interfaces: ip addr show. SSH Client Debugging: Use ssh -v hostname or ssh -vv hostname to see detailed connection debugging output, including DNS resolution attempts. This is invaluable for troubleshooting.

Frequently asked questions

What does "ssh: Could not resolve hostname hostname: Name or service not known" mean?
This error occurs when the SSH client attempts to connect to a remote server but cannot resolve the hostname to an IP address. The system's DNS resolver (or local hosts file) is unable to translate the hostname you provided into a valid IP address. This can happen due to DNS server unavailability, incorrect hostname, network connectivity problems, or misconfigured DNS settings on your local machine.
How do I fix "ssh: Could not resolve hostname hostname: Name or service not known"?
SSH cannot translate the hostname to an IP address due to DNS resolution failures, incorrect hostname spelling, network connectivity issues, or misconfigured DNS settings. Fix by verifying hostname spelling, checking DNS resolution, updating /etc/hosts, or using the IP address directly.
What causes "ssh: Could not resolve hostname hostname: Name or service not known"?
Typo or misspelling in the hostname you're trying to connect to DNS servers are unreachable or not responding to queries Hostname does not exist in DNS or is not properly registered
Is the "ssh: Could not resolve hostname hostname: 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