How to use multiplexing in SSH

SSH (Secure Shell) multiplexing enables several remote shells, file transfers, and tunnels to reuse a single encrypted connection to a host. Reusing an already authenticated session removes repeated key exchanges and logins, which reduces latency and resource usage when many short commands or scripted operations target the same server.

Multiplexing relies on a master connection controlled by the ControlMaster option and a local Unix-domain socket defined by ControlPath. Subsequent SSH invocations that match the same host pattern connect to this socket instead of opening a new TCP session, and the master forwards traffic for the additional shells or port-forwardings.

Persistence is governed by ControlPersist, which keeps the master connection alive for a configured duration after the last client exits or until explicitly closed. The configuration below assumes a recent OpenSSH client and a private directory for socket files on a multi-user system, keeping control sockets readable only by the account that created them.

1. Open a terminal for the user account that initiates SSH connections.
2. Open or create the per-user OpenSSH client configuration file.

   $ vi ~/.ssh/config

   Per-user configuration in ~/.ssh/config overrides matching settings from the system-wide /etc/ssh/ssh_config file.

3. Add or update a host block that enables multiplexing, persistence, and the control socket path for matching hosts.

   Host *
     ControlMaster auto
     ControlPersist 10m
     ControlPath ~/.ssh/muxmasters/%C

   * matches every host; narrow the pattern for critical systems with a more specific name such as Host prod-servers.

   Enabling multiplexing globally can reuse authentication across sessions that are expected to be isolated, especially on shared bastion hosts or accounts with different privilege levels.

4. Create the directory that will hold multiplexing control sockets.

   $ mkdir -p ~/.ssh/muxmasters

   The ControlPath directory must exist before OpenSSH can create control sockets inside it.

5. Tighten permissions on the SSH configuration and control-socket directories.

   $ chmod 700 ~/.ssh ~/.ssh/muxmasters

   World-writable or group-writable socket directories cause OpenSSH to refuse multiplexing because other users could hijack sessions.

6. Start a master SSH connection to a target host using the new configuration.

   $ ssh -v user@remotehost
   ##### snipped #####
   debug1: Control socket "/home/user/.ssh/muxmasters/1234567890abcdef" does not exist
   debug1: Control master enabled, establishing master connection
   debug1: Control socket "/home/user/.ssh/muxmasters/1234567890abcdef" created
   ##### snipped #####

   Verbose mode highlights creation of the master connection and the associated control socket path.

7. Confirm that the master connection created a control socket in the configured directory.

   $ ls -l ~/.ssh/muxmasters
   total 0
   srw------- 1 user user 0 Dec 11 12:34 1234567890abcdef

   The s file type indicates a Unix-domain socket, confirming that multiplexing is active.

8. Open a second SSH session to the same host to reuse the master connection.

   $ ssh -v user@remotehost
   ##### snipped #####
   debug1: Control socket "/home/user/.ssh/muxmasters/1234567890abcdef" connected
   debug1: multiplexing control connection
   ##### snipped #####

   Additional sessions connect through the existing master connection and typically skip password or key passphrase prompts.

9. Check the status of the multiplexed master connection from another terminal when ongoing activity needs to be inspected.

   $ ssh -O check user@remotehost
   Master running (pid=12345)

   Control operations such as check use the same host pattern and ControlPath defined in the client configuration.

10. Terminate the master connection when multiplexing is no longer required.

    $ ssh -O exit user@remotehost
    Exit request sent.

    Shutting down the master connection closes all multiplexed shells and port-forwardings that rely on it.