Wandering Thoughts archives

The basics of ssh's connection sharing feature

Vaguely recent versions of OpenSSH have a feature where you can have multiple independent sessions running over what is actually one connection, even though you ran several separate ssh commands. The primary advantage this offers is that new ssh sessions start significantly faster, since they don't have to go through all of the cryptography and authentication of a full ssh connection. (As a side benefit, there's fewer processes running on either side, since you no longer need a ssh and an sshd for each active session.)

When I first tried this, it didn't work too well; it would slowly eat resources and the connection would lock up every so often. These days it seems to work fine between at least Ubuntu 8.04 and Fedora 11.

Connection sharing has two parts; there is a single master ssh and then some number of subordinate ssh sessions that reuse the master's connection instead of making their own. There are two .ssh/config settings that control this behavior:

• ControlMaster determines whether a ssh becomes a connection master (and what it does if a would-be subordinate tries to talk to it).
• ControlPath tells both master and subordinates how to find each other. The value I use for this is:

  /u/cks/.ssh/control/cs-%r@%h:%p

  (You should also use %l in there somewhere if you have a shared home directory; the machine I use this from doesn't, so I don't bother.)

One of the drawbacks of a master ssh is that it doesn't exit until the last subordinate exits. Thus, automatically creating ssh masters can be a bad idea; imagine the annoyance of, say, your first login session somewhere not exiting when you ^D it, because there's still a subordinate ssh active. Master processes can be explicitly created by using ssh's -M command line option, which is equivalent to specifying either yes or auto for the ControlMaster setting (depending on how many -M's you use).

(Although it's unlikely to matter in most circumstances, another drawback of this connection sharing is that there is only a single ssh and sshd doing all of the encryption and decryption, which can be slow. If you have multiprocessor machines of some sort and are doing multiple high-bandwidth bulk transfers, you're probably better off with entirely separate connections.)

There are three situations where I think that connection sharing is likely to be a significant benefit: if your link is slow (so that the back and forth exchanges of the ssh protocol take a significant amount of time due to packet delays), if either machine is quite slow (so that all of the computation involved in a full ssh connection takes quite a while), or if you create and throw away sessions quite a lot, so you want them to be as cheap and as fast to start as possible.

(As it happens, the last one describes my typical usage pattern.)