The message on each system
The first part comes from SSH. The part after the colon comes from your system's resolver.
ssh: Could not resolve hostname server: nodename nor servname provided, or not knownThat is macOS. On Linux the same failure reads:
ssh: Could not resolve hostname server: Name or service not knownLinux also has a third form, which is common when the network or the DNS server is down:
ssh: Could not resolve hostname server: Temporary failure in name resolutionThe word between hostname and the colon is exactly what SSH tried to look up. Read it first, because it often shows the mistake.
Cause 1: a typo, or an alias SSH cannot see
ssh -G server | grep -E '^(hostname|port|user) 'This prints what SSH would use, without connecting. If you expected an alias from your config and hostname just repeats what you typed, then no Host block matched. Check these:
- The alias is spelled the same way in
~/.ssh/config. - The block has a
HostNameline, and that line has no typo. A wrong value there shows up in the error in place of the alias. - You are the same user.
sudo ssh serverreads root's config, not yours.
How aliases and Host blocks match is explained with ssh config file examples.
Cause 2: the port or a URL is part of the name
SSH does not read host:port or a web address. These two fail with the same error, and the error shows the whole string as the name:
ssh user@example.com:22
ssh https://example.comssh: Could not resolve hostname example.com:22: nodename nor servname provided, or not knownUse one of these forms:
ssh -p 2222 user@example.com
ssh ssh://user@example.com:2222A stray space gives a different message, hostname contains invalid characters. Check for pasted spaces or line breaks.
Cause 3: DNS
Check the name outside SSH, using the resolver SSH uses.
On macOS:
dscacheutil -q host -a name example.comOn Linux:
getent hosts example.comEmpty output means this machine cannot resolve the name. Then ask a public resolver directly:
dig +short example.com @1.1.1.1- An answer from the public resolver but not from your system: your local DNS setup or cache is at fault. Flush it, on macOS with
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderand on systemd Linux withresolvectl flush-caches, or switch DNS server. - No answer anywhere: the record does not exist. It may be a new record that has not spread yet, a removed one, or a typo in the zone.
For a name that only you use, such as a machine at home, you can skip DNS: add a line to /etc/hosts, or put the address in the HostName line of your ~/.ssh/config.
To get to work while you sort out DNS, connect by address. Keep in mind that the host key is saved per name, so SSH may ask you to confirm it again:
ssh user@203.0.113.10Cause 4: a name that exists only on a private network
Company names, .internal names and Tailscale MagicDNS names resolve only while you are on that network. If it worked yesterday, check that the VPN is on and that it set its DNS server.
Names ending in .local depend on mDNS. macOS handles them out of the box. On Linux they usually need Avahi and mdns4_minimal in /etc/nsswitch.conf. Guest Wi-Fi networks often block mDNS between devices.
Cause 5: no network
Temporary failure in name resolution usually means the system could not reach a DNS server at all. Check with an address that needs no name:
ping -c 1 1.1.1.1On a Linux server or container, also look at /etc/resolv.conf.
Questions
What does "nodename nor servname provided, or not known" mean?
It is the macOS wording for a failed name lookup. SSH found no IP address for the name, so check the spelling, the alias in ~/.ssh/config and your DNS.
Can I write the port after a colon in ssh?
No. ssh reads host:22 as part of the name. Use ssh -p 22 user@host, or the form ssh://user@host:22.
Why does it fail only with sudo?
sudo ssh reads root's ~/.ssh/config, not yours, so your aliases are unknown there. Run ssh without sudo.