How to configure SSH multiplexing

Repeated SSH commands against the same server can spend more time negotiating and authenticating than doing work. SSH multiplexing keeps one master connection open and lets later shells, file transfers, and tunnels attach to it, so short administrative tasks start without another full login.

OpenSSH enables client-side multiplexing with ControlMaster, ControlPath, and ControlPersist. The master connection listens on a local control socket, and later ssh commands that match the same host block use that socket before falling back to a normal connection.

Use multiplexing in a specific Host block instead of a broad default when some hosts should remain isolated. The control socket directory should exist before the first connection and should be writable only by the account that owns the SSH session, because access to the socket can grant access to the live master connection.

1. Open or create the per-user OpenSSH client configuration file.

   $ vi ~/.ssh/config

   Per-user settings in ~/.ssh/config override matching defaults from /etc/ssh/ssh_config for the same Host match.

2. Add a host block for the target that should use multiplexing.

   ~/.ssh/config

   Host host-mux
       HostName host.example.net
       User user
       IdentityFile ~/.ssh/id_ed25519
       ControlMaster auto
       ControlPersist 10m
       ControlPath ~/.ssh/muxmasters/%C

   Use a dedicated alias such as host-mux when only one target should reuse the master connection. The %C token expands to a hash of the connection details, which keeps socket names unique without exposing the full hostname.
   Tool: SSH Config Snippet Generator

   A broad Host * multiplexing block can share authentication across sessions that should stay separate, especially on bastions or accounts with different privilege boundaries.

3. Create the directory that will hold the control sockets.

   $ mkdir -p ~/.ssh/muxmasters

4. Restrict access to the SSH directory and socket directory.

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

   OpenSSH recommends placing ControlPath sockets in a directory that other users cannot write to.

5. Restrict access to the client configuration file.

   $ chmod 600 ~/.ssh/config

6. Check the resolved client configuration for the alias.

   $ ssh -G host-mux
   host host-mux
   user user
   hostname host.example.net
   port 22
   ##### snipped #####
   controlmaster auto
   ##### snipped #####
   controlpath /home/user/.ssh/muxmasters/c0657b039ebf877ae442037457ed8bc9ce0ffd90
   ##### snipped #####
   identityfile ~/.ssh/id_ed25519
   ##### snipped #####
   controlpersist 600
   ##### snipped #####

   ssh -G prints the effective client settings after Host matching, user config, and system defaults are merged, without opening a network session. OpenSSH normalizes ControlPersist 10m to 600 seconds.
   Related: How to show SSH client configuration

7. Start the multiplexing master connection in the background.

   $ ssh -fN host-mux

   -N opens no remote command, and -f backgrounds the connection after authentication. If the host key is new, verify the fingerprint before accepting it.

8. Confirm that the master connection is running.

   $ ssh -O check host-mux
   Master running (pid=85)

   ssh -O check sends a control command through the configured ControlPath and reports whether the master process is reachable.

9. List the control socket created by the master connection.

   $ ls -l ~/.ssh/muxmasters
   total 0
   srw------- 1 user user 0 Jun 13 11:17 c0657b039ebf877ae442037457ed8bc9ce0ffd90

   The leading s in srw——- identifies a Unix-domain socket, which is the local listener used for multiplexed sessions.

10. Open a second session through the same alias with verbose output.

    $ ssh -v host-mux hostname
    debug1: OpenSSH_10.2p1 Ubuntu-2ubuntu3.2, OpenSSL 3.5.5 27 Jan 2026
    ##### snipped #####
    debug1: auto-mux: Trying existing master at '/home/user/.ssh/muxmasters/c0657b039ebf877ae442037457ed8bc9ce0ffd90'
    debug1: mux_client_request_session: master session id: 2
    host

    The mux_client_request_session line confirms that the second ssh command attached to the existing master instead of opening a new TCP connection.

11. Close the test master connection after verification.

    $ ssh -O exit host-mux
    Exit request sent.

    ssh -O exit closes the master and any sessions or port forwardings that depend on it. Use ssh -O stop instead when existing sessions should continue but new multiplexed sessions should be refused.
    Related: How to stop SSH multiplexing