Speed Up Repeated SSH Logins with Multiplexing (ControlMaster)

Why Use SSH Multiplexing?

Every SSH session starts with a full TCP handshake, key exchange, and authentication. When you run many commands or open several terminals to the same host, that overhead repeats. Multiplexing lets a single TCP connection serve multiple logical sessions, cutting latency by a few milliseconds and reducing CPU load on both client and server.

How It Works

OpenSSH creates a UNIX domain socket (the control socket) that all client processes attach to. The first client that starts a connection becomes the master. Subsequent clients detect the socket, connect to the master, and send their session requests. The master forwards these requests over the single TCP stream. When the master exits, all attached sessions terminate.

Configuring ControlMaster

Add the following to ~/.ssh/config to enable multiplexing for all hosts. Adjust paths and timeouts to suit your environment.

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

• ControlMaster auto – the first connection becomes the master; later connections reuse it.
• ControlPath – location of the socket. The pattern uses remote username, host, and port to keep sockets unique.
• ControlPersist 10m – keeps the master alive for 10 minutes after the last session closes, so a quick reconnect uses the same master.

Practical Example

1. Run ssh [contact removed].
   • The client creates ~/.ssh/[contact removed]:22 and starts the master process.
   • You log in, run commands, and exit.
2. Immediately run ssh [contact removed] again.
   • OpenSSH sees the existing socket, attaches to the master, and reuses the TCP connection.
   • Login is instant; no key exchange is performed.

Verifying the Master Exists

Use the -O check flag:

ssh -O check [contact removed]
# Exit code 0 means a master is running, 1 means none.

List active sockets:

ls -l ~/.ssh/cm-*

Terminate the master when you want to force a fresh connection:

ssh -O exit [contact removed]

Limitations & Common Mistakes

• Resource Drain – The master process keeps the TCP connection and the background SSH daemon alive. On a busy host, many masters can consume memory and CPU.
• Incompatibility with ProxyCommand – When you use ProxyCommand or ProxyJump, multiplexing is disabled for those connections because the control socket cannot be shared across the tunnel.
• Different Options Per Session – Options like ForwardAgent or IdentityFile that differ between sessions cannot be multiplexed; the master inherits the first session’s options.
• Stale Sockets – If the network changes or the host is rebooted, the socket may become orphaned. Running ssh -O check will fail; you can delete the stale socket manually.
• Permissions – The ~/.ssh directory must be 0700 to prevent other users from creating sockets that hijack the master.

When Not to Use Multiplexing

• If you rely on per‑session agent forwarding and start the master without -A, agent forwarding may fail.
• In environments where the SSH daemon is heavily restricted (e.g., PermitOpen or AllowTcpForwarding limits) and you need isolated connections.
• When you need to run commands that require a fresh key exchange for security reasons (e.g., one‑time tokens).

Conclusion

SSH multiplexing is a lightweight, built‑in optimization that can noticeably speed up repeated connections to the same host. By configuring ControlMaster auto, a unique ControlPath, and a reasonable ControlPersist timeout, you reduce handshake overhead and free system resources. Just be mindful of the limitations and verify that the master is running with ssh -O check before relying on it. With proper setup, you’ll experience near‑instant logins and a smoother workflow.