Reducing SSH Latency with ControlMaster Multiplexing

The problem: repeated SSH handshakes

\n

Every time you run ssh user@host true the client performs a TCP three‑way handshake, negotiates encryption, exchanges keys and authenticates. For short‑lived tasks such as a git push or a remote script this overhead can dominate the total latency.

\n\n

What ControlMaster multiplexing does

\n

SSH can keep a single authenticated connection alive and reuse it for subsequent logical sessions. When the first connection is established it becomes the master; later client invocations attach to the same master over a Unix domain socket, skipping the expensive handshake and authentication steps.

\n\n

Enabling ControlMaster in ~/.ssh/config

\n

Host *\n    ControlMaster auto\n    ControlPath ~/.ssh/cm-%r@%h:%p\n    ControlPersist 10m\n

\n

\n
• ControlMaster auto tells SSH to use an existing master socket if one is present, otherwise to start a new master connection.
\n
• ControlPath defines the location of the socket file; the tokens %r (remote user), %h (remote host) and %p (port) make the path unique per target.
\n
• ControlPersist keeps the master open for the given time after the last client session ends, allowing quick reuse without holding the socket indefinitely.
\n

\n

Place the socket in a directory that only your user can read (the default ~/.ssh is usually 700). If other local users could access the socket they could hijack the multiplexed connection.

\n\n

Worked example: timing a git push

\n

Before enabling multiplexing you might see a connection time of roughly 200 ms (this varies with network and key type). After adding the configuration above, a second git push that reuses the master can drop to the low‑tens of milliseconds because only the multiplex socket negotiation occurs.

\n

To illustrate the reuse you can run:

\n

# Check whether a master socket exists for [contact removed]:22\nssh -O check -S ~/.ssh/[contact removed]:22 [contact removed]\n# If the command returns 0, a master is active.\n

\n

Then, with the master active, a subsequent command such as:

\n

time ssh [contact removed] true\n
\n
should report a shorter real time than the first run that created the master.
\n
Note: the numbers above are illustrative; actual measurements depend on your environment.
\n\n
Trade‑offs and limitations
\n
\n
Socket security: the control socket must be protected; a permissive directory could allow another local user to attach to your SSH sessions.
\n
Persistence window: a long ControlPersist value keeps the master alive longer, increasing the window where a stolen socket could be misused. Shorter intervals reduce risk but may cause the master to close before you finish a batch of commands.
\n
Compatibility: very old SSH clients (pre‑5.3) lack multiplexing support; ensure both ends run a recent enough version.
\n
\n
You can verify that a master is active with ssh -O check -S  user@host and list existing sockets with ls -l ~/.ssh/cm-*. To terminate a master explicitly run ssh -O exit -S  user@host.
\n\n
Actionable closing
\n
If you frequently run short SSH‑based commands, add the three directives shown above to your ~/.ssh/config, restrict the socket directory to your user, and pick a ControlPersist value that matches your workflow (e.g., 5 minutes for intermittent work, 30 minutes for a long session). Test the reuse with the ssh -O check command and monitor the socket files to confirm they appear and disappear as expected. This simple change can shave off hundreds of milliseconds per command and reduce CPU load on both client and server.