== 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
SshSpeed]]. 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
../unix/PersistentVsDisposableUsage]].)