The Latency Problem with SSH
Secure Shell (SSH) is the bedrock of remote Linux administration. However, establishing a new SSH connection is computationally expensive and slow. Every time you connect, your client and the server must perform a TCP handshake, exchange cryptographic keys, authenticate your credentials, and establish an encrypted tunnel. If you are running an automation script (like Ansible or rsync) that opens and closes dozens of SSH connections in a short period, or if you are connecting to a server with high network latency, this repeated handshake overhead can cause agonizing delays.
SSH Multiplexing solves this problem. It allows multiple SSH sessions to share a single, underlying TCP connection. You pay the handshake penalty once on the initial connection. Any subsequent connections to the same server—whether in a new terminal window or triggered by a background script—piggyback on the existing tunnel, dropping your connection time from seconds to milliseconds.
How to Enable SSH Multiplexing
Multiplexing is a client-side configuration. You do not need to modify anything on the remote server to use it.
Step 1: Edit the SSH Config File
Open your local SSH configuration file using your preferred text editor (like nano):
nano ~/.ssh/configNote: If the file does not exist, simply creating it with nano is fine.
Step 2: Add the Multiplexing Directives
Add the following configuration block to the file. This applies the settings to all hosts (Host *), but you can restrict it to specific servers if you prefer.
Host *
ControlMaster auto
ControlPath ~/.ssh/sockets/%r@%h:%p
ControlPersist 10m
Understanding the Directives
ControlMaster auto: This tells SSH to act as a “master” connection and accept multiplexed sessions if one doesn’t exist, or act as a “slave” and piggyback if a master connection is already active.ControlPath: This defines where SSH should store the temporary Unix socket file used to manage the connections.%ris the remote username,%his the host, and%pis the port. We place this inside a~/.ssh/sockets/directory.ControlPersist 10m: This tells the master connection to remain open in the background for 10 minutes after your last terminal window is closed. If you reconnect within 10 minutes, it will be instantaneous.
Step 3: Create the Sockets Directory
Because we defined a specific directory for the socket files in the ControlPath, we must create that directory, or SSH will throw an error.
mkdir -p ~/.ssh/socketsTesting the Speed Difference
To see the massive speed improvement, close all active SSH connections to your remote server.
- Open a terminal and connect to the server:
ssh user@server_ip. This first connection will take the normal amount of time (perhaps 1-2 seconds) while it establishes the master socket. - Leave that terminal open. Open a second terminal window on your local machine.
- Connect to the exact same server again:
ssh user@server_ip.
You will notice that the second terminal connects instantly, without prompting for a password or key phrase, because the authentication and cryptography were already handled by the first connection.
Managing Multiplexed Connections
Because the connection persists in the background (due to ControlPersist), you might sometimes need to forcefully close it (for example, if the remote server rebooted and your socket is hanging).
To check if a master connection is running for a specific host:
ssh -O check user@server_ipTo forcefully close the background master connection:
ssh -O exit user@server_ipConclusion
If you regularly work with remote servers or use tools that rely on SSH under the hood, enabling SSH multiplexing is the single most impactful configuration change you can make. It entirely eliminates the cryptographic overhead of repeated logins, making your remote terminal feel as snappy as your local machine.