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.
$ vi ~/.ssh/config
Per-user configuration in ~/.ssh/config overrides matching settings from the system-wide /etc/ssh/ssh_config file.
Host host-mux HostName host.example.net User user IdentityFile ~/.ssh/id_ed25519 ControlMaster auto ControlPersist 10m ControlPath ~/.ssh/muxmasters/%C
Use a dedicated host alias (like host-mux) when you want multiplexing enabled for a specific target.
Enabling multiplexing broadly can reuse authentication across sessions that are expected to be isolated, especially on shared bastion hosts or accounts with different privilege levels.
$ mkdir -p ~/.ssh/muxmasters
The ControlPath directory must exist before OpenSSH can create control sockets inside it.
$ chmod 700 ~/.ssh ~/.ssh/muxmasters
World-writable or group-writable socket directories cause OpenSSH to refuse multiplexing because other users could hijack sessions.
$ ssh -v host-mux hostname ##### snipped ##### debug1: auto-mux: Trying existing master at '/home/user/.ssh/muxmasters/79b54c680bc3a687c54a4b2e86e6605d44c58129' debug1: Control socket "/home/user/.ssh/muxmasters/79b54c680bc3a687c54a4b2e86e6605d44c58129" does not exist ##### snipped ##### debug1: setting up multiplex master socket debug1: channel 0: new mux listener [/home/user/.ssh/muxmasters/79b54c680bc3a687c54a4b2e86e6605d44c58129] (inactive timeout: 0) debug1: control_persist_detach: backgrounding master process ##### snipped #####
Verbose mode highlights creation of the master connection and the associated control socket path.
$ ls -l ~/.ssh/muxmasters total 0 srw------- 1 user user 0 Jan 10 13:51 79b54c680bc3a687c54a4b2e86e6605d44c58129
The s file type indicates a Unix-domain socket, confirming that multiplexing is active.
$ ssh -v host-mux hostname ##### snipped ##### debug1: auto-mux: Trying existing master at '/home/user/.ssh/muxmasters/79b54c680bc3a687c54a4b2e86e6605d44c58129' debug1: mux_client_request_session: master session id: 2 ##### snipped #####
Additional sessions connect through the existing master connection and typically skip password or key passphrase prompts.
$ ssh -O check host-mux Master running (pid=13677)
Control operations such as check use the same host pattern and ControlPath defined in the client configuration.
$ ssh -O exit host-mux Exit request sent.
Shutting down the master connection closes all multiplexed shells and port-forwardings that rely on it.