Reuse SSH Connections to Cut Latency with ControlMaster

The Hidden Cost of Short-Lived SSH Sessions

Every time you run ssh, scp, or git fetch over SSH, your client opens a new TCP connection to the server, performs a cryptographic key exchange to establish encryption keys, and then authenticates you. For a single interactive login this overhead is negligible. For scripts, CI jobs, or rapid Git operations that invoke SSH dozens of times per minute, the repeated handshake adds measurable latency and consumes extra server resources.

SSH connection multiplexing removes that repetition. With a small configuration change, the first SSH connection becomes a “master” that stays open, and every subsequent connection to the same host rides on the existing authenticated channel instead of negotiating a new one.

How ControlMaster Multiplexing Works

Three directives in your SSH client configuration control this behavior:

• ControlMaster — set to auto, tells the client to create a master connection if none exists, or reuse an existing one.
• ControlPath — defines the filesystem path to a Unix domain socket. This socket is the rendezvous point: new client processes connect to it to piggyback on the master session.
• ControlPersist — keeps the master connection open in the background for a specified time after the last logical session closes, so short gaps between commands do not force a new handshake.

A Unix domain socket is a local inter-process communication endpoint. Because it lives on the filesystem, its permissions matter: if another user can write to or access the socket, they may be able to inject commands into your multiplexed session.

A Worked Example

Add the following to your local ~/.ssh/config file. You need write permission to that file; the directory ~/.ssh should be mode 700 so only your user can read it.

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

The placeholders %r (remote username), %h (host), and %p (port) keep sockets distinct when you connect to different servers or accounts.

To establish the master, run a trivial command over SSH from your local machine:

ssh user@host true

Replace user and host with your actual credentials and target. The expected check is exit status 0 and the appearance of a socket file such as ~/.ssh/cm-user@host:22. You can confirm it with:

ls -l ~/.ssh/cm-user@host:22

Now run another SSH command—for example, a Git operation or scp—and it will reuse the master connection without re-authenticating. To verify the master is alive, use the control command:

time ssh -O check user@host

The -O check option asks the control socket whether a master is running; it should return quickly and indicate a master is active.

Trade-offs and Limitations

Multiplexing introduces a single point of failure. If the underlying TCP connection drops—because of a network change, NAT timeout, or server restart—every session attached to that master terminates immediately. A stable connection benefits most; a flaky network may make the failure mode more annoying than the saved handshakes.

Stale control sockets can also linger if a master process crashes without cleaning up. Because ControlPersist holds the socket open for a grace period, a crashed network may leave a socket file that no longer works. Removing the file manually is safe, but only if you are certain no live master is using it.

Finally, avoid multiplexing on shared bastion hosts where strict session isolation and per-connection auditing are required. Because multiple logical sessions share one authenticated channel, audit logs on the server may record them as a single connection, obscuring which command belonged to which logical session.

Verification and Rollback

To prove the change works, compare connection latency before and after. Run time ssh user@host true without multiplexing to measure a full handshake. After enabling ControlMaster, run time ssh -O check user@host to confirm the master is reachable; the near-instant response reflects that no new cryptographic negotiation is occurring. The difference between the two timings reflects the handshake overhead you are avoiding.

If you need to revert, edit ~/.ssh/config and either delete the ControlMaster, ControlPath, and ControlPersist lines or prefix them with #. Then terminate any active master with:

ssh -O exit user@host

After that, new SSH connections will perform the full handshake again. Monitor the ~/.ssh directory periodically for orphaned socket files, and set ControlPersist to a value that matches your workflow—long enough to bridge gaps between commands, short enough to release server resources when you are idle.