MacOS – ssh to non-existent .local name never times out

dnsmacosssh

If I try to connect to a non-existent .local hostname using most utilities, including ping and telnet, it times out after 5 seconds:

% time telnet host.example.local
host.example.local: nodename nor servname provided, or not known
telnet host.example.local  0.01s user 0.01s system 0% cpu 5.018 total

This matches the timeout for the .local config in scutil --dns.

But when I try to ssh to such a hostname, it never times out. (I just Ctrl-C'd one that was still waiting after 16 minutes.) I can't figure out any existing option in any of the ssh_config files that would seem to affect hostname resolution. The only option I see that seems relevant is "CanonicalizeHostname", and it's not configured in any config file, but I manually set it to "no" with no change in behavior. Adding -v flags to ssh doesn't reveal any additional information about hostname resolution beyond the fact that it's "Connecting to host.example.local port 22", which is the last debug line produced.

I tried capturing the MDNS queries for telnet and ssh. It appears to make an initial query, then wait 1s and ask again, then again 3s later, etc., each retry waiting 3 times longer than the last. telnet gave up after three requests (0s, 1s, and 3s), but ssh got up to the seventh request (0s, 1s, 3s, 9s, 27s, 81s, 243s) before I stopped watching.

I can kind of work around the problem by setting ConnectTimeout 5 in ssh_config (even limiting it to *.local), but that breaks if the name resolution completes but the remote ssh server is slow to respond.

How can I get ssh to timeout name resolution in the same manner as other network tools?

Best Answer

Rather than make a bunch of comments, here’s how I would start to corner this. I can’t reproduce this yes, so I might be totally wrong.

First, does ssh using a known bad local IP address time out fast or understandably / reliably?

Second, does the potential (or any) machine show as advertised?

 dns-sd -B _ssh._tcp local

Third, do you have any apple device that’s proxying bonjour sleep wake?

If not, why even try ssh to something that mdns could dig up later or have bonjour sleep proxy trying to keep waking that device. I could see how this longer time-out is by design to allow WOL via sleep proxy and multiple network segments to have a chance to wake your sleeping beautiful Mac.

Related Question