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
then some number of subordinate
ssh sessions that reuse the master's
connection instead of making their own. There are two
settings that control this behavior:
ControlMasterdetermines whether a
sshbecomes a connection master (and what it does if a would-be subordinate tries to talk to it).
ControlPathtells both master and subordinates how to find each other. The value I use for this is:
(You should also use
%lin 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
ssh active. Master processes can be explicitly created by
-M command line option, which is equivalent to specifying
auto for the
ControlMaster setting (depending on how
-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:Written on 07 August 2009.