SSH connection sharing and erratic networks

March 29, 2015

In the past I've written about SSH connection sharing and how I use it at work. At home, though, while I've experimented with it I've wound up abandoning SSH connection sharing completely because it turns out that SSH connection sharing has a big drawback in the sort of networking environment I have at home.

Put simply, with connection sharing, if one SSH session to a host stalls or dies they all do. With connection sharing, all of your separate-looking sessions are running over one underlying SSH transport stream and one underlying TCP connection. In a reliable networking environment, this is no problem. In a networking environment where you sometimes experience network stalls or problems, this means that the moment you have one, all of your connections stall and you can't make new ones. You get to wait out TCP retransmission timeout delays and so on, for everything. And if there's an interruption that's long enough to cause an active session to close itself, you lose everything, including the inactive sessions that would have otherwise survived.

It turns out that this is really annoying and frustrating when (or if) it happens. On the university network at work, it basically never comes up (especially since most of the machines I do this to are on the same subnet as my office workstation), but from home the network stalls, dropped ACKs, and outright brief connection losses happened too often for me to keep my sanity in the face of this. The minor savings in latency for new connections weren't worth the heartburn when something went wrong.

(The most irritating things were and are generally retransmit timeouts. When the network comes back you can easily get into a situation where your new SSH session is perfectly active but the old session that had some output and thus a transmit timeout during the network interruption is just sitting there silently waiting for the TCP timeout to expire and a retransmit to kick off. This can happen on either end, although often it will happen on your end because you kept typing even as the network path was failing.)


Comments on this page:

By Paul Tötterman at 2015-03-29 05:52:13:

What do you think about mosh for less reliable networks?

By cks at 2015-03-30 14:27:19:

I haven't looked much at mosh. My off the cuff reaction is that my network is not that unreliable and I trust ssh's connection security much more than I do mosh's. Mosh's UDP protocol may be secure, but there are tons of ways to screw up cryptography and security in this sort of environment and mosh simply hasn't had the attention that ssh has. They even admit this straight up in their FAQ.

(Also, that mosh doesn't support ssh-agent forwarding is fatal for an important part of my home to office ssh'ing.)

Written on 29 March 2015.
« All browsers need a (good) way to flush memorized HTTP redirects
The 'cattle' model for servers is only a good fit in certain situations »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Mar 29 03:04:39 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.