How to check SSH multiplexing session status

Monitoring the status of multiplexed SSH connections avoids surprises when many shells, tunnels, or automation tasks reuse the same TCP connection. When a single master connection silently dies or stalls, new clients can fail in confusing ways and long‑running jobs may lose their control channel unexpectedly.

In OpenSSH multiplexing, a master connection created with ControlMaster and ControlPath listens on a Unix domain socket, and subsequent sessions attach to that socket instead of opening new TCP connections. The socket path, often under /tmp or /home in a dedicated directory, is the main indicator that a multiplexing master is alive and accepting new clients.

Status checks focus on three pieces of information: whether the control socket exists and is open, whether the associated ssh process is still running, and whether ssh -O check can talk to the master. The examples assume a POSIX shell with OpenSSH on Linux or a similar Unix‑like system; care is required when using ssh -O exit or ssh -O stop, because those control commands can disconnect other sessions that rely on the same master connection.

1. Open a terminal on the client system that establishes multiplexed connections.

   $ whoami
   user

2. Inspect the effective configuration for the target host to confirm multiplexing settings.

   $ ssh -G host-mux | grep -iE 'control(master|path|persist)'
   controlmaster auto
   controlpath /home/user/.ssh/muxmasters/79b54c680bc3a687c54a4b2e86e6605d44c58129
   controlpersist 600

   The generated ssh -G output shows the final ControlMaster, ControlPath, and ControlPersist values after all configuration files are merged.

3. Identify the concrete control socket path that corresponds to the expanded ControlPath pattern.

   $ ssh -G host-mux | awk '$1 == "controlpath" {print $2}'
   /home/user/.ssh/muxmasters/79b54c680bc3a687c54a4b2e86e6605d44c58129

   The %C token in ControlPath expands to a hash of the connection parameters, so reading the resolved path from ssh -G is the simplest way to find the socket.

4. List the control socket on disk to verify that a multiplexing master is currently listening.

   $ ls -l /home/user/.ssh/muxmasters/79b54c680bc3a687c54a4b2e86e6605d44c58129
   srw------- 1 user user 0 Jan 10 13:55 /home/user/.ssh/muxmasters/79b54c680bc3a687c54a4b2e86e6605d44c58129

   A srw——- entry indicates a Unix stream socket, which is the usual type for the OpenSSH control master.

5. Examine the ssh process that owns the control socket to confirm the master is still running.

   $ ps aux | grep ssh | grep -E 'master|mux'
   user       14473  0.0  0.1  18252  4920 ?        Ss   13:55   0:00 ssh: /home/user/.ssh/muxmasters/79b54c680bc3a687c54a4b2e86e6605d44c58129 [mux]

   Command lines containing \[mux] or similar labels identify multiplexing master processes serving one or more control sockets.

6. List open Unix sockets that reference the control path to see how many file descriptors reference the master.

   $ lsof -U | grep /home/user/.ssh/muxmasters/79b54c680bc3a687c54a4b2e86e6605d44c58129
   ssh       14473 user    4u  unix 0x0000000000000000      0t0 71787 /home/user/.ssh/muxmasters/79b54c680bc3a687c54a4b2e86e6605d44c58129.cx3xzBqSgI15kQ9u type=STREAM (LISTEN)

   Multiple file descriptors to the same control socket usually indicate active or recently active multiplexed sessions.

7. Query the multiplexing master directly using the ssh -O check control command.

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

   A Master running response confirms that the master process is reachable via the control socket and is accepting multiplexed connections.

8. Increase verbosity when additional diagnostics are needed about the control connection.

   $ ssh -vvv -O check host-mux
   OpenSSH_9.6p1 Ubuntu-3ubuntu13.14, OpenSSL 3.0.13 30 Jan 2024
   ##### snipped #####
   debug1: auto-mux: Trying existing master at '/home/user/.ssh/muxmasters/79b54c680bc3a687c54a4b2e86e6605d44c58129'
   debug2: mux_client_hello_exchange: master version 4
   debug3: mux_client_request_alive: done pid = 14473
   Master running (pid=14473)

   Verbose output with -vvv helps trace configuration loading, control socket negotiation, and potential permission or path issues.

9. Optionally stop an unwanted or stale multiplexing master once status has been confirmed.

   $ ssh -O stop host-mux
   Stop listening request sent.

   Stopping the master with ssh -O stop prevents new multiplexed sessions from attaching but allows existing sessions to finish; using ssh -O exit would immediately terminate all sessions that share the same master.

   Related: How to stop multiplexing sessions in SSH

10. Verify the final status by running another check against the same host.

    $ ssh -O check host-mux
    Control socket connect(/home/user/.ssh/muxmasters/79b54c680bc3a687c54a4b2e86e6605d44c58129): No such file or directory

    Failure to connect to the control socket after stop indicates that the master has removed its listener and multiplexing is no longer active for that host.