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

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:

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

Correct format:

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)

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

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:

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.

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

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:

systemd-resolve --status

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

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.

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

ssh [email protected]
ssh [email protected]

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.

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

sudo nano /etc/hosts

Add a line in the format IP_ADDRESS hostname:

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:

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.

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

nano ~/.ssh/config

Look for incorrect HostName entries or duplicate host definitions:

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:

ssh myserver    # Uses alias from config

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

cat /etc/nsswitch.conf | grep hosts

Typical output:

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:

hosts: files dns

To fix, edit it:

sudo nano /etc/nsswitch.conf

Change the hosts line if needed and save.

Ensure your machine can reach external networks and DNS servers:

# 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:

# Ubuntu/Debian
sudo ufw status

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