Reusing SSH Connections: How ControlMaster Cuts Latency in Repeated Sessions

Running ssh user@host uptime in a shell loop feels cheap until you measure it. Every invocation negotiates a new TCP connection, performs a fresh cryptographic handshake, and re-authenticates before the command even starts. On a high-latency link, or inside automation that fires dozens of short-lived sessions, that repeated setup dominates the total runtime.

SSH multiplexing removes most of that overhead. By setting ControlMaster and ControlPath in your client configuration, the first connection becomes a long-lived master that listens on a local Unix domain socket. Subsequent SSH commands attach to that socket as slaves, skipping the network handshake and reusing the already-authenticated session.

How multiplexing works under the hood

A standard SSH connection carries three phases: TCP establishment, key exchange, and user authentication. Multiplexing collapses those phases into a one-time cost.

When ControlMaster is set to auto, the first SSH process for a given destination creates a Unix domain socket—a local inter-process communication endpoint that behaves like a file on disk. That process becomes the master and holds the authenticated network connection open. Later SSH invocations detect the socket, hand their session data to the master, and return output without opening a new TCP connection.

The ControlPath directive defines where that socket lives. The ControlPersist directive controls how long the master stays alive after the last slave disconnects, which is what makes the feature useful for scripts: the socket survives between separate command invocations.

Configuring ControlMaster in ~/.ssh/config

The directives belong in your per-user SSH client configuration file, typically ~/.ssh/config. Because this file affects every connection you make, keep its permissions restrictive: the ~/.ssh directory should be mode 700, and the config file itself mode 600.

Directive	Purpose	Example
ControlMaster	Enables or disables multiplexing	auto
ControlPath	Template for the Unix socket path	~/.ssh/cm-%r@%h:%p
ControlPersist	Keeps master alive after last slave exits	10m

A minimal block looks like this:

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

The %r, %h, and %p tokens expand to the remote username, hostname, and port, so each destination gets a distinct socket. If you prefer to scope multiplexing to a single host, replace Host * with a specific pattern such as Host build-server.

Verifying that connections are actually reused

Before relying on multiplexing, confirm your client supports it. Run ssh -V in your terminal. ControlMaster has been available since OpenSSH 5.6, released in 2009, but heterogeneous fleets may still contain older builds.

Next, measure the difference. Run time ssh user@host true twice in a row. The first call establishes the master; the second should return noticeably faster because it reuses the existing transport.

To see the mechanism directly, run ssh -vv user@host true. Verbose output should indicate that the control master is enabled and that the client is connecting to the local socket rather than negotiating a new network session.

Finally, confirm the socket exists and is shared. On Linux, lsof -U ~/.ssh/cm-* or ss -x will list active Unix domain sockets owned by your user; inspecting sockets belonging to other accounts may require elevated privileges. You should see the master SSH process holding the socket open while slave processes communicate through it.

If you need to force a fresh connection for testing, either remove the socket file or set ControlPersist to 0, which disables background persistence entirely.

Trade-offs: persistence, staleness, and security

Multiplexing introduces a stateful resource that plain SSH does not have: the socket file and the master process behind it.

Stale sockets. If the remote host reboots or the network drops, the master connection dies but the socket file can remain. A subsequent SSH command may hang while trying to reach a dead master. Short ControlPersist values—say 1m or 5m—limit the window, and manually removing orphaned ~/.ssh/cm-* files clears the problem.

Shared authentication. All slave sessions inherit the master's authenticated identity. If an attacker compromises the master connection or the local socket, they gain the same access as every multiplexed session. Protect the master with strong key-based authentication, restrict socket permissions, and avoid long ControlPersist durations on shared or untrusted machines.

Compatibility. Very old clients lack ControlMaster. If you administer a mixed environment, verify versions before depending on the feature.

What to do next

Add the three directives to ~/.ssh/config, keeping the socket path unique per destination. Test with time ssh user@host true and inspect the socket with lsof -U ~/.ssh/cm-*. If you write scripts that call SSH repeatedly, multiplexing turns a per-command handshake into a one-time setup cost.

To revert, simply remove the added lines from ~/.ssh/config and delete any lingering socket files under ~/.ssh/cm-*; new connections will fall back to the standard behavior.