≡ Menu

Linux / Unix: OpenSSH Multiplexer To Speed Up OpenSSH Connections

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
  HostName server1.cyberciti.biz
  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 server1.cyberciti.biz : 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 user@host
$ ssh root@v.server1
$ ssh nixcraft@192.168.1.219

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
OR
$ ssh -O check root@v.server1
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 root@v.server1

Pass the exit option instead of stop to cancel all existing connections, including the master connection:
$ ssh -O exit host
$ ssh -O exit root@v.server1

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 $HOME/.ssh/master-root@v.server1: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.

Share this tutorial on:

Your support makes a big difference:
I have a small favor to ask. More people are reading the nixCraft. Many of you block advertising which is your right, and advertising revenues are not sufficient to cover my operating costs. So you can see why I need to ask for your help. The nixCraft, takes a lot of my time and hard work to produce. If you use nixCraft, who likes it, helps me with donations:
Become a Supporter →    Make a contribution via Paypal/Bitcoin →   

Don't Miss Any Linux and Unix Tips

Get nixCraft in your inbox. It's free:



{ 9 comments… add one }
  • Anthony Ruiz May 7, 2015, 12:57 am

    Does this multiplexing also work to speed up scp transfers?

  • Alex May 7, 2015, 6:59 am

    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.

  • Benjamin May 8, 2015, 10:33 am

    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.

  • Grant May 12, 2015, 4:20 pm

    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

  • Leon June 6, 2015, 7:24 am

    I think the title is misleading. The reason has been explained by other guys.

  • SC January 11, 2017, 6:35 pm

    I always start a background connection to start and hold open the channel.

    ssh -MNf host

    • SC January 11, 2017, 6:38 pm

      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.

  • Daniel January 12, 2017, 12:18 pm

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

  • PGF January 12, 2017, 2:05 pm

    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.

Leave a Comment

You can use these HTML tags and attributes: <strong> <em> <pre> <code> <a href="" title="">


   Tagged with: , ,