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:
- Use existing unix socket
- No new TCP/IP connection
- No need to key exchange
- 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:
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.
9 comment
Does this multiplexing also work to speed up scp transfers?
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.
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.
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
I think the title is misleading. The reason has been explained by other guys.
I always start a background connection to start and hold open the channel.
ssh -MNf host
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.
How does this impact connection rate-limiting firewall rulesets? and utilities like SSHGuard and Fail2Ban?
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.