18

When I try to SSH to a host on the network named storage, I get a DNS resolution failure:

$ ssh storage
ssh: Could not resolve hostname storage: Name or service not known

But when I query DNS with host, it works

$ host storage
storage has address 192.168.20.103

How is it that host can find the IP but ssh cannot?

8
  • 14
    Start getting into the habit of using FQDNs everywhere. If this is the first problem you've had along these lines, you're extraordinarily fortunate. These can be really hairy to track down, and it won't be your last. Here's a hint: storage is a live top-level domain on the Internet. Feb 10 '17 at 6:05
  • Are you able to 'ssh' to 192.168.20.103? Feb 10 '17 at 6:18
  • 2
    Where have you define the hostname of 192.168.20.103? /etc/hosts?
    – Orphans
    Feb 10 '17 at 7:30
  • 4
    Typing FQDNs is a pain. Aliasing "storage" to "storage.mydomain.com" in .ssh/config, on the other hand, is really handy.
    – pjc50
    Feb 10 '17 at 12:28
  • 1
    @pjc50 I type sto and then hit Tab. Feb 10 '17 at 15:55
35

ssh and host resolve names following completely different paths, so it is not surprising that they yield different results sometimes, especially when the name to resolve is not a FQDN (hence the suggestion to use FQDNs everywhere.)

You don’t mention anything about your OS and your system configuration, so I have to keep it general, with an eye on Linux: MacOS details are somewhat different, and Windows even more, but the general concepts are the same.

  • host queries DNS, so basically it looks in /etc/resolv.conf and queries the servers listed there, possibly attaching a domain name if the hostname is not already fully qualified. It ignores every other possible source, but beware that these days many systems run a local caching DNS server (usually dnsmasq) which reads /etc/hosts and other sources before querying other DNS servers, so if host queries that local server, results from /etc/hosts can creep in.

  • ssh follows its own path. I will describe what openssh does under Linux, other implementations differ. First it looks for host nicknames defined in config files (system-wide /etc/ssh/ssh_config and per-user ~/.ssh/config), then it searches other sources in the order specified by the hosts: directive in /etc/nsswitch.conf. Say it is something like:

    hosts: files dns
    

    this means: look in /etc/hosts and then query the DNS (/etc/resolv.conf again). Other possible sources are the obsolete nis and netinfo services, LDAP, active directory, you name them.

To debug your particular case, you should follow the path your implementation of ssh follows and find out where it gets stuck.

2
  • 6
    ltrace/strace can give you hints at how ssh is actually trying to resolve the domain... and the closest-to-how-the-os-does it, command line dns tool is probably getent. Feb 10 '17 at 15:54
  • Your recommendation of changing /etc/nsswitch.conf to read hosts: files dns worked for me. Just as an interesting side note, I've set up several Raspberry Pis with Raspian Jessie the past few weeks, and they've all required this change. May 25 '17 at 15:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.