Related links
-
Jay R Wren on SSH Multiplexing
Jay R Wren talks about SSH multiplexing, and its uses for compiling. Several of the comments are useful too.
Nick Burch, 12 April 2006
SSH has a number of very useful features that aren't widely known about. In this part, we look at the new ControlMaster/ControlPath feature of OpenSSH 4, and how it allows for persistent connections and multiplexing of interactive connections in one session. (Part 2 of 2, see part 1)
In the first part, we looked at how SSH can be used to carry multiple different connections over one session, and how this can be used to forward ports between machines. In this, we look at a new feature in OpenSSH v4, which allows multiple interactive connections to share one session.
With OpenSSH v4, there have been two new options introduced, ControlMaster and ControlPath. If an SSH session has ControlMaster enabled, it will open a unix domain socket on your local machine. Other SSH sessions you initiate to the same machine may connect to the ControlMaster via the unix domain socket. The master SSH session then creates another interactive connection within the existing session, which your second SSH uses.
Because the existing session is re-used, the connection setup is very much faster. There is no need to pull up a new TCP/IP connection, no need for key exchange, and no need for authentication. The master simply requests another interactive connection, and you're there.
The very nice thing about this is that it uses existing functionality of the protocol, and so requires no changes server side (and hence will work with older SSH servers without change). All the new logic is on the client side, so all you need to do is update your client to take advantage of it.
Setting your ControlPath
Before you go ahead and use this new feature, it's worth tweaking the default ControlPath option (which controls where slave sessions look for the unix domain socket). Normally you'll want connections to different machines and usernames to have different ControlPath's (if they tried to share the same one, you'd end up connected to the wrong machine!). So, if you drop this into the start of you ~/.ssh/config file:
# Where to find the control path, if we have one
Host *
ControlPath ~/.ssh/master-%r@%h:%p
Then the requested username, port and hostname all need to be the same before a control master will be used by subsequent sessions.
ControlMaster Options
You don't have to always have your sessions being ControlMaster ones. You can either enabled it on the command line (by adding the -M option), or in your ssh config file (by adding a ControlMaster entry under a host definition). There are several ControlMaster options to choose from:
- auto - if you are the first session, be a ControlMaster, otherwise use the existing ControlMaster
- yes - always become a ControlMaster
- no - never be a ControlMaster (but use an existing one if found) (default)
- ask - listen for ControlMaster connections, but require confirmation from the user before allowing them to use the existing session
- autoask - combination of auto and ask
Persistent Connections
Finally, we have the option to have a single persistent SSH session, which all other ones make use of. Simply fire one off with "ssh -MNf hostname", and once you've authenticated, it'll place itself in the background, as a ControlMaster. All other connections to that username+machine will connect over the ControlMaster, allowing you very fast setup and teardown of SSH sessions - ideal for when you're making lots of short connections (eg with distcc).ssh/config
In this, we've made use of the per-user ssh config file. This is another very powerful feature of ssh, and allows you to define a whole group of options for named sessions (eg "ssh work" -> "hostname is login.mycompany.com, username is nb9911122, port is 2233, local forward port 2525 to smtp.mycompany.com:25"). "man ssh_config" will tell you all about it, it's well worth a read.
