[Update -- Solved(?): See my answer below w/ my solution. I'm still not sure why my symptoms (seem to have) changed from timing-out-entirely to taking-3-min-before-succeeding, though, which is what let me debug & find a workaround.]

When I try to ssh to my mac OS machine, it times out (as if nothing was listening to the port -- telnet'ing to port 22 also times out). I can ping the machine successfully, so the network connection seems plausible, and I can ssh from the target machine to itself (localhost), so it is actually listening to port 22. In fact, I can't telnet in to any port on that machine.

[add'l fact: I set up a web-server on port 8080, and likewise I can't connect to it from other machines, but I can confirm it really is listening to the port. So it seems this is a network/port/firewall issue, and nothing ssh-specific.]

System Preferences looks okay (Sharing has Remote Login turned on for all users, and Firewall Options confirms "Remote Login(SSH)" is "Allow incoming connections" (screenshot here). And launchctl seems to show that sshd is running.

I can go from that machine to another mac OS machine I have -- so it doesn't seem to be a router problem either [although: one machine is connected via ethernet, and the troublesome machine is connected via wireless]. As far as I can tell, I have both macs configured the same way.

Everything was working fine a couple weeks ago; I've installed a system update since then. Maybe I've changed some system-setting in the mean time; I don't remember changing anything. (The only other difference, as mentioned: one machine is connected to my router by ethernet, the other by wireless.)

Evidence that the machine ("tropic") is indeed listening to port 22 with sshd: it can see itself via localhost:

tropic> telnet localhost 22
Trying ::1...
Connected to localhost.
Escape character is '^]'.

and also sudo launchctl list com.openssh.sshd prints about 20 lines that look the same as a "correct" version on somebody else's post.

BUT when trying to connect from another machine ("equator"):

equator> ssh -vvv tropic.local
OpenSSH_7.4p1, LibreSSL 2.5.0
debug1: Reading configuration data /Users/ibarland/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolving "tropic.local" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to tropic.local [] port 22.
ssh: connect to host tropic.local port 22: Operation timed out

The network connection is okay:

equator> ping -c 2 tropic.local
PING tropic.local ( 56 data bytes
64 bytes from icmp_seq=0 ttl=55 time=17.424 ms
64 bytes from icmp_seq=1 ttl=55 time=19.654 ms

--- tropic.local ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 17.424/18.539/19.654/1.115 ms

Other things I've tried/verified: I've turned off the firewall entirely (on both computers), and I have tried disabling my router's firewall -- none of those made any difference. Both sides are running the same version of ssh. Both have been re-booted; I've made sure both have the latest system-update.

I've been hitting my head against this wall all afternoon; any insight, debugging-strategies, or other suggestions would be appreciated. (I couldn't find any system-log messages generated by the port-listener, if there are any.)

  • Try turning your firewall off again and telnetting to the machine. It sounds like you may need to enable the sshd-keygen-wrapper setting but that wouldn't make sense if it still didn't work with the firewall completely disabled. It could also be a permission issue with your $HOME/.ssh directory and/or the files in it. Make sure you own them and have the proper permissions to them.
    – jesse_b
    Jul 13, 2017 at 22:44

1 Answer 1


Not sure this was (the entire) problem, but I solved an issue related to timeouts:

(a) A solution -- or at least a workaround -- was to edit /etc/ssh/ssh_config:

Host tropic

(presumably this change would also work in ~/ssh/ without needing root privileges)

(b) the problem was a very-long (~3min) ssh timeout: ssh -vvv revealed that it was trying to connect twice using a MAC address; when it finally got around to trying an IP address it connected quickly. [Though my question from 2 weeks ago seems to have been failing with a timeout after a few minutes; not sure how that was different when I revisited the problem this morning, when would eventually connect but only after several minutes.]

(c) Sadly, this replicates IP-addrs I also specify in /etc/hosts -- perhaps adding info to that file had triggered some of my issues?

(d) Fwiw, my problem was NOT solved via changing ssh_config lines regarding GSSAPIAuthentication or GSSAPIDelegageCredentials, nor by changing sshd_config's option UseDNS.

  • 1
    SSH cannot connect with a MAC address. It does not run on a protocol that uses MAC addresses. However, it may have been trying to connect with an IPv6 address (which is considerably longer than a MAC address, but some parts can be omitted). If DNS returned an IPv6 address but the IPv6 connection failed (e.g. due to incomplete IPv6 support or due to a firewall blocking it), specifying an explicit IPv4 address would indeed solve the problem. In this case, another solution that doesn't hard-code the address would be AddressFamily inet. Nov 21, 2021 at 21:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .