How To Reuse SSH Connection To Speed Up Remote Login Process Using Multiplexing

How do I reuse same ssh connection (Multiplexing) to speed up remote login procedure with OpenSSH client?

You can reuse the connection to the remote server using controlmaster directive. To enables the sharing of multiple sessions over a single network connection to add controlmaster after host directive. When set to yes ssh client will listen for connections on a control socket specified using the ControlPath argument. These sessions will try to reuse the master instance’s network connection rather than initiating new ones, but will fall back to connecting normally if the control socket does not exist, or is not listening. Multiplexing is nothing but the ability to send more than one signal over a single line or connection. OpenSSH can re-use an existing TCP connection using multiplexing.

WARNING! These examples requires OpenSSH version 4.0 or higher.

Setting up ssh multiplexing

Open ~/.ssh/config file (ssh client configuration file). If you need system wide settings add to the /etc/ssh/ssh_config file:
$ vi ~/.ssh/config
Append following code to reuse ssh connection for all hosts:

host *
    controlmaster auto
    controlpath /tmp/ssh-%[email protected]%h:%p

Where,

  1. controlmaster auto: Set controlmaster to auto
  2. controlpath /tmp/ssh-%[email protected]%h:%p: Specify the path to the control socket used for connection sharing. In the path, %h will be substituted by the target host name, %p the port, and %r by the remote login username. It is recommended that any ControlPath used for opportunistic connection sharing include at least %h, %p, and %r. This ensures that shared connections are uniquely identified.

You can also match any host in the 192.168.0.[0-9] network range with following pattern:

Host 192.168.0.?
    controlmaster auto
    controlpath ~/.ssh/ssh-%[email protected]%h:%p

For any host in the “.co.in” set of domains, reuse the connection:

Host *.co.in
    controlmaster auto
    controlpath ~/.ssh/private/master-%[email protected]%h:%p

Save and close the file. Now connect as usual,
$ ssh [email protected]
Next, time you connect again it will use connection socket /tmp/[email protected]:22 to speed up things. You don’t have to input password or anything else. You need one connection to be active for the second to be accelerated. This also works with scp / sftp etc:
$ scp /path/to/file.txt [email protected]:/tmp

Compare ssh command with and without multiplexing

You can compare the time it takes to run command on a slow remote server, using time. First, run time command without multiplexing (remove entries from ~/.ssh/config file):
$ time ssh [email protected] /path/to/command
$ time ssh -o 'ControlMaster=no' [email protected] /bin/true

Sample outputs:

real	0m3.546s
user	0m0.016s
sys	0m0.008s

Now, run same command with multiplexing (add entries to ~/.ssh/config):
$ time ssh [email protected] /path/to/command
$ time ssh [email protected] /bin/ture

Sample outputs:

real	0m0.621s
user	0m0.006s
sys	0m0.004s

How to disable multiplexing for a single ssh command session?

Run command as follows with ControlMaster set to no:
$ ssh -o 'ControlMaster=no' [email protected]

How to find out or check the status of multiplexing

$ ssh -O check [email protected]
Sample outputs:

Master running (pid=64134)

How to stop multiplexed connections

To gracefully shutdown multiplexing pass the -O stop option to the ssh command:
$ ssh -O stop [email protected] [email protected]
Sample outputs:

Stop listening request sent.

Pass the -O exit option to remove the control socket and immediately terminates all existing connections, run:
$ ssh -O exit [email protected]@vpn.nixcraft.co.in
Sample outputs:

Exit request sent.

And all of your ssh session will terminated with the following message:

Shared connection to vpn.nixcraft.co.in closed.

A sample session output

Fig.01: A sample session

Using ssh multiplexing with ProxyCommand

You can go through one host to reach another server. In this example, you reach to internal host called 10.70.203.66 via vpn.nixcraft.co.in:

Host internal
  HostName 10.70.203.66
  User vivek
  ProxyCommand ssh [email protected] -W %h:%p
  ControlPath ~/.ssh/controlmasters/%[email protected]%h:%p
  ControlMaster auto

Just type the following command to go through ‘vpn.nixcraft.co.in’ to reach another server called ‘internal’:
$ ssh internal

Say hello ControlPersist option

When ControlPersist used in conjunction with ControlMaster, specifies that the master connection should remain open in the background (waiting for future client connections) after the initial client connection has been closed. You can set it as follows:

  1. ControlPersist no : The master connection will not be placed into the background, and will close as soon as the initial client connection is closed.
  2. ControlPersist yes : The master connection will remain in the background indefinitely (until killed or closed via a mechanism such as the ssh -O exit [email protected] option. Further, if set to yes then, if set to a time in seconds, or a time in any of the formats documented in sshd_config(5), then the backgrounded master connection will automatically terminate after it has remained idle (with no client connections) for the specified time. For example, ControlPersist 10m.

Here is an updated config file:

Host internal
  HostName 10.70.203.66
  User vivek
  ProxyCommand ssh [email protected] -W %h:%p
  ControlPath ~/.ssh/controlmasters/%[email protected]%h:%p
  ControlMaster auto
  ControlPersist yes

A note about X11, ssh-agent and port forwarding

Please note that X11 and ssh-agent forwarding is supported over these multiplexed connections, however the display and agent forwarded will be the one belonging to the master connection i.e. it is not possible to forward multiple displays or agents. However, you can create new session as follows for port forwarding:
$ ssh -M -S /tmp/3001.port.forwording -L 3001:localhost:3001 -N -f [email protected]

Further readings:
  • man pages ssh_config(5)

Posted by: SXI ADMIN

The author is the creator of SXI LLC and a seasoned sysadmin, DevOps engineer, and a trainer for the Linux operating system/Unix shell scripting. Get the latest tutorials on SysAdmin, Linux/Unix and open source topics via RSS/XML feed or weekly email newsletter.