Linux / Unix: OpenSSH Multiplexer To Speed Up OpenSSH Connections

Posted on in Categories , , , , , , , last updated January 11, 2017

How can I multiplex SSH sessions by setting up a master session and then having subsequent sessions go through the master to speed up my ssh connection on a Linux or Unix-like operating systems?

Multiplexing is nothing but send more than one ssh connection over a single connection. OpenSSH can reuse an existing TCP connection for multiple concurrent SSH sessions. This results into reduction of the overhead of creating new TCP connections. First, you need to set a ControlMaster to open a Unix domain socket locally. Rest of all your ssh commands connects to the ControlMaster via a Unix domain socket. The ControlMaster provides us the following benefits:

  1. Use existing unix socket
  2. No new TCP/IP connection
  3. No need to key exchange
  4. No need for authentication and more

How to setup up multiplexing

Edit $HOME/.ssh/config, enter:
vi ~/.ssh/config
Append the following configuration:

Host *
    ControlMaster auto
    ControlPath ~/.ssh/master-%r@%h:%p.socket
    ControlPersist 30m

Here is another example:

Host server1
  Port 2222
  ControlPath ~/.ssh/ssh-mux-%r@%h:%p
  ControlMaster auto
  ControlPersist yes

Save and close the file. Where,

  • Host * or Host server1 : Start ssh configuration.
  • HostName : The real hostname
  • ControlPath ~/.ssh/ssh-mux-%r@%h:%p : Specify the path to the control unix socket used for connection sharing as described above. The variables ‘%r’, ‘%h’, ‘%p’ refer to remote ssh username, remote ssh host, and remote ssh port respectively. You need to set all of these three variables.
  • ControlMaster auto : Enables the sharing of multiple sessions over a single network connection. When set to yes, ssh will listen for connections on a control socket specified using the ControlPath argument. When set to auto, ssh will try to use a master connection but fall back to creating a new one if one does not already exist.
  • ControlPersist 10m : Specifies that the master connection should remain open in the background for 10 minutes. With no client connections, the backgrounded master connection will automatically terminate after it has remained idle for 10 minutes. If set to yes, then the master connection will remain in the background indefinitely (until killed or closed)

How do I use it?

Simply start running ssh commands:
$ ssh [email protected]
$ ssh [email protected]
$ ssh [email protected]

How do I verify that Multiplexer is working?

Use any one of the following command to verify that Multiplexer is working properly:
$ lsof -U | grep master
$ ssh -O check [email protected]
Sample outputs:

Fig.01: SSH Multiplexing Check The Status of The Connection
Fig.01: SSH Multiplexing Check The Status of The Connection

Can I tell master connection not to accept further multiplexing requests?

Yes, use the following syntax:
$ ssh -O stop host
$ ssh -O stop [email protected]

Pass the exit option instead of stop to cancel all existing connections, including the master connection:
$ ssh -O exit host
$ ssh -O exit [email protected]

How do I the port forwarding?

The syntax is as follows to forward port 3128 on the local host to port 3128 on the remote host using -L:
ssh -O forward -L 3128:localhost:3128 v.server1
You can also specifies the location of a control socket for connection sharing:
ssh -O forward -L 3128:localhost:3128 -S [email protected]:22 v.server1

The main advantage with SSH multiplexing is that the overhead of creating new TCP connections is removed. SSH client activities that repeatedly open new connections can be significantly speed up using multiplexing. See ssh_config man page for more information.

Posted by: Vivek Gite

The author is the creator of nixCraft and a seasoned sysadmin and a trainer for the Linux operating system/Unix shell scripting. He has worked with global clients and in various industries, including IT, education, defense and space research, and the nonprofit sector. Follow him on Twitter, Facebook, Google+.

9 comment

  1. This method just “reduction of the overhead of creating new TCP connections”.
    If you want to speedup work on host – use gnu screen – “Ctrl+a c” – “Create new window”, and you not won’t to create new connection – you work in unified space.

  2. Thanks for the post; I didn’t know this was possible with OpenSSH alone. Perhaps this is no so wide-spread because similar behaviour can be achieved using a terminal multiplexer like screen or tmux? Technically it works different, but as a user you won’t notice the different. When wrapped with byobu these multiplexers become really fancy.

    @Anthony Ruiz: it’s doesn’t really speed up transfer speed. It just saves you the split second it normally takes to set up a new connection.

  3. Yes, ssh master connections (multiplexing) does impact any subsequent connections to the same server, including ssh, scp, sftp, as well as anything that uses these, i.e. rsync.

    Connection multiplexing eliminates the time that it takes to establish a connection and authenticate. Some of the networks that I work on this takes between 15 and 30 seconds. As such, all subsequent operations are quite a bit faster using multiplexing.

    It is not always possible to leverage things like screen / tmux. I quite frequently am running a script on my local system that establishes a master connection to a server and then runs a series of commands remotely via ssy and / or scp files back and forth.

    ssh -o BatchMode=yes -o ConnectTimeout=90 -fMN $server
    ssh -o BatchMode=yes -t $server remoteCommand1
    ssh -o BatchMode=yes -t $server remoteCommand2
    ssh -o BatchMode=yes -t $server remoteCommand3
    scp -o BatchMode=yes /local/path/$file $server:/remote/path/$file
    ssh -o BatchMode=yes -t $server remoteCommand4
    ssh -o BatchMode=yes -t $server sudo remoteCommand5
    ssh -o BatchMode=yes -t $server sudo remoteCommand6
    ssh -O exit $server

    This allows me to run all but the first command extremely quickly even if the connection takes 30+ seconds to establish (i.e. b/c of DNS problems).

    Further, I get to use any and all tools installed on my local system for my business logic. I don’t have to worry about what tools are and are not installed on the remote system.

    There is extreme power in this type of remote command execution that can’t be matched by terminal multiplexers.

    Grant. . . .
    unix || die

    1. Sorry, to be clear, I mean I use the control master setup above, and then I start a background process for the hosts I most commonly use everyday.

  4. How does this impact connection rate-limiting firewall rulesets? and utilities like SSHGuard and Fail2Ban?

  5. SSH multiplexing allows you to complete the handshake once, and then establish multiple channels over the same connection. This is advantageous in two situations. One, if you are using extremely slow, old systems. Two, if you are going to establish very frequent connections from the same client to the same host. Outside this, SSH multiplexing won’t make any noticeable difference.

Comments are closed.