The SSHv2 protocol allows multiple shell channels to be opened using only one authenticated connection. This is particularly useful for servers which require passwords instead of key authentication, or S/Key.
Recent versions of OpenSSH have the facility to open a local UNIX socket on the client machine, and use that for subsequent connections to the same server. In OpenSSH 4.2 the 'ControlMaster Auto' option and the expansion of '%h', '%p' and '%r' in the 'ControlPath' option make this fairly easy to use. However it's still slightly lacking
With this set of patches, you can achieve transparent connection re-use by adding something like the following to your ~/.ssh/options file:
Host *
ControlPath ~/.ssh/sockets/%p-%h-%r
ControlMaster auto
ControlPersist yes
Do consider the security implications of this -- you will be leaving
sockets around which can be re-used when you've gone. You may want to
disable it for certain targets, or maybe to enable it only
for certain targets instead of for 'Host *' as in the above
example. See also the '-O exit' command-line option, to
force given masters to quit.
OpenSSH v4.3 lacks an option to leave the master behind even after its own primary session has finished -- using the 'ControlMaster Auto' feature only allows you to re-use connections if the second and subsequent connections attempts happen before the master has finished.
openssh-4.3p2-controlpersist.patch provides a ControlPersist option, which causes OpenSSH to fork and remain in the background, continuing to service further clients.
When used in 'Auto' mode, a stale UNIX socket will prevent OpenSSH v4.2 from being able to connect. It will attempt to use the stale socket, and will fall back to making its own connection to the server after that fails. But then it will abort when it is unable to create the same socket again in order to become a master.
openssh-4.2p1-controlcleanup.patch will cause OpenSSH to unlink the original socket if an ECONNREFUSED error occurs when attempting to connect to it.
The remaining patches address X11 forwarding with multiple displays. OpenSSH v4.2 will simply use the $DISPLAY of the master for all clients, which isn't always desireable.
openssh-4.2p1-controldisplay.patch augments the protocol used between OpenSSH control client and master, to pass the X11 display and authentication data to the master.
openssh-4.3p2-multidisplay.patch makes the X11 forwarding code capable of handling multiple displays. Although the SSHv2 protocol doesn't allow the SSH server to distinguish between displays when passing a connection request back to the client, the X11 protocol allows use to work around that -- we can infer which of the displays to use from the X11 authentication data used.