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
   username

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

   $ ssh -G user@remotehost | grep -iE 'control(master|path|persist)'
   controlmaster auto
   controlpath /tmp/ssh-%r@%h:%p
   controlpersist 10m

   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.

   $ printf '/tmp/ssh-%s@%s:%s\n' "user" "remotehost" "22"
   /tmp/ssh-user@remotehost:22

   Format placeholders like %r, %h, and %p expand to the remote user, host, and port when a multiplexed session is created.

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

   $ ls -l /tmp/ssh-user@remotehost:22
   srw------- 1 username username 0 Jun 30 20:15 /tmp/ssh-user@remotehost:22

   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'
   username  35857  0.0  0.0 410883376   1920  ?  Ss  20:15   0:00 ssh: /tmp/ssh-user@remotehost:22 [mux]
   username  35854  0.0  0.0 411015568   2528  ?  Ss  20:15   0:00 ssh: /tmp/ssh-otherhost:22 [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 /tmp/ssh-user@remotehost:22
   ssh     35857 username    3u  unix 0x64513004a8a01fe6      0t0  /tmp/ssh-user@remotehost:22
   ssh     35857 username    6u  unix 0xaf4cb928ce99e1c9      0t0  /tmp/ssh-user@remotehost:22

   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 user@remotehost
   Master running (pid=35857)

   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 user@remotehost
   OpenSSH_9.3p1, OpenSSL 3.0.2 15 Mar 2022
   debug1: Reading configuration data /home/username/.ssh/config
   ##### snipped #####
   debug1: mux_client_request_session: master session id: 2
   Master running (pid=35857)

   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 user@remotehost
   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 user@remotehost
    Control socket connect(/tmp/ssh-user@remotehost:22): 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.