The basics of ssh's connection sharing feature

August 7, 2009

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.)


Comments on this page:

From 203.206.102.50 at 2009-08-07 09:34:14:

I use connection sharing a lot at work, it's incredibly useful because like you, I can start a new SSH session every time I start a new piece of work. I automate the master connection setup by reading hostnames out of ~/.ssh/known_hosts (make sure HashKnownHosts is off) and starting a backgrounded ssh session with it (ssh -Nf $host &).

The biggest disadvantage for me is that starting extra SSH-using apps and making them not use the master multiplex is Hard (add -S none ). Since my shell does tab-completion for processes with the kill command, I just kill the relevant master and recreate it after.

--NT

Written on 07 August 2009.
« A rule for Internet software
How I use ssh's connection sharing feature »

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

Last modified: Fri Aug 7 02:40:57 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.