I've been ssh'ing into a specific server from my home office via Wifi and Time Warner Cable internet for years with no problem.

In recent months, I started having problems, where I'd be unable to ssh in to that server (I'd get ssh login time outs) for periods of several minutes, then for no apparent reason everything would work normally. I can't detect any pattern to when it works and when it doesn't; just seems like it's a few minutes working, a few minutes not working. Also, sometimes after ssh'ing in successfully my connection would just freeze at random times, even when I'm just idle on the command line.

Clues: 1. When I get the ssh time outs with this particular server from my computer, I immediately try ssh'ing into a different server and never have problems. 2. Likewise, when I get the ssh time outs, I try to ssh into the same server with my phone on the same Wifi network, and ALSO get time outs. 3. If, at the same time as the time outs are happening, I ssh into the same server on my phone via 4G, I get in with no problems.

This suggests the problems is something to do with my Wifi router or Time Warner connection and how they interact with the specific server I'm trying to get into.

That's as much as I've been able to figure out. What are the next things I should check to figure out this mystery?

  • One likely explanation is a PMTU discovery issue. Another is that your connection is going through an overloaded NAT box. It might also be that you are going through a buggy NAT box, I have heard about NAT boxes that would erroneously create a new connection tracking entry if the type-of-service field changed during the connection, which it sometimes does with ssh. – kasperd Oct 29 '14 at 18:01
  • Thanks @kasperd -- any tips on how I can confirm whether it's a PMTU or NAT issue? – Ghopper21 Oct 29 '14 at 18:06
  • If you can reduce the MSS to something low (like 400 or so), then you can expect PMTU discovery issues to go away. For example if you have anything running iptables on the path between client and server, you could try using --set-mss 400 and see if that makes the problem go away. – kasperd Oct 29 '14 at 18:17
  • The type-of-service issue could be worked around using ProxyCommand. Even ProxyCommand='nc %h %p' which is almost a no-op would be sufficient to work around that particular NAT bug. If you happen to be dealing with an overloaded NAT box, you can try using ServerAliveInterval=25. This won't reduce the load on the NAT box, but it may work around the problem for yourself at the cost of making the problem worse for other users of the NAT box. – kasperd Oct 29 '14 at 18:21

Your Answer

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

Browse other questions tagged or ask your own question.