Improve the speed SSH can run commands on remote servers with the help of multiplexing.
How many times do you log in and out of your remote servers during the day? If you admin an entire data center of Linux servers, that answer can get dizzying. Even better, how often do you regularly execute commands on remote hosts (via SSH)? If you use SSH in such a manner (as in ssh USER@HOST COMMAND) you might get frustrated with the speed at which this is accomplished. Wouldn’t it be nice if there was a method to make the process a bit more efficient? Fortunately, for every busy admin on the planet, there is. Said method is called multiplexing.
Multiplexing SSH connections allows you to work with multiple SSH sessions over a single TCP connection. The biggest advantage of using multiplexing is that it speeds up certain operations that occur over SSH (such as running commands).
SEE: Windows 10 security: A guide for business leaders (TechRepublic Premium)
How does this work? Effectively, SSH can use an existing TCP connection for multiple, concurrent sessions, which results in a reduction in overhead for new TCP connections.
I’m going to show you how to configure multiplexing on a Linux client connecting to a remote Linux server.
SSH can use a handy config file for each user on a given machine. Create that file with the command:
Paste the following at the beginning of that file:
Host * ControlMaster auto ControlPath ~/.ssh/master-%r@%h:%p.socket
The above file will work if you connect to multiple networks (such as on your LAN and/or outside of the WAN). The breakdown of that configuration is:
- Host – name of the connection
- ControlMaster – enables the sharing of multiple sessions over a single network connection. When set to auto, SSH will attempt to use a master connection but will fall back to a new connection if one doesn’t exist.
- ControlPath – the path to the control unix socket used for connection sharing. The variables are: %r remote username, %h remote host, and %p remote port.
Let’s say you tend to connect to multiple servers. You can add the HostName entry and define a specific remote servers like so:
Host DOCKERMASTER HostName 192.168.1.71 ControlMaster auto ControlPath ~/.ssh/ssh-%r@%h:%p Host HARBOR HostName 192.168.1.75 ControlMaster auto ControlPath ~/.ssh/ssh-%r@%h:%p
Create as many entries as you need. Save and close that file.
Making the connection
Let’s say you’ve created an entry for DOCKERMASTER and HARBOR. You could then connect to them with the following SSH commands:
ssh USERNAME@DOCKERMASTER ssh USERNAME@DOCKERMASTER
Where USERNAME is a username on the remote machines.
Or you could issue a command to one of those remote servers like so:
ssh jack@DOCKERMASTER 'ls /etc/docker/certs.d/192.168.1.75'
Verify it’s working
If you want to make sure multiplexing is working, ssh to one of your hosts listed in the config file and then issue the following command on the client:
ssh -0 check USERNAME@HOST
Where USERNAME is the remote username and HOST is the host you connected to. You should see the master is running and the associated PID for the service (Figure A).
If you find yourself leaving connections open and idle for longer periods, you can define the ControlPersist option in the config file such that it will remain open in the background for a specified time. That option would look like:
Host HARBOR HostName 192.168.1.75 ControlMaster auto ControlPath ~/.ssh/ssh-%r@%h:%p ControlPersist 30m
The above configuration would leave the master connection open for 30 minutes (even if idle).
SSH sped up
With multiplexing in place, your SSH actions (for logging in, running commands, etc.) should be more efficient. Give this a try and see if it doesn’t make your daily admin life a bit less frustrating at the command prompt.