SSH Connection Multiplexing: Unclear Upper Bound on Concurrent Sessions per Master

Question

GoalConfigure OpenSSH to reuse a single TCP connection for multiple user sessions, aiming to reduce per‑session latency under concurrent requests.Constraints and UncertaintyOpenSSH exposes ControlMaster, ControlPath, and ControlPersist to enable multiplexing, but the only documented limit is MaxSessions (default 10).  It is not specified whether this limit applies globally or per‑master connection, nor how the server behaves when the limit is reached—whether new multiplexed requests are queued, rejected, or silently dropped.  This ambiguity can lead to unpredictable latency spikes or connection failures when many clients attempt to share a single master socket.Unresolved QuestionsDoes MaxSessions apply per‑master connection or to all concurrent sessions across all masters?What is the exact rejection policy when the session limit is exceeded—does the client receive an immediate error or is the request retried?Is there a recommended configuration or workaround to guarantee a predictable upper bound on multiplexed sessions per master?

Tasadduq Burney · Answer

AnswerOpenSSH’s MaxSessions directive limits the number of concurrent multiplexed sessions (channels) on a **single master TCP connection**, not across all masters.Confirmed factsMaxSessions is evaluated per‑master connection; each master socket enforces its own limit.When the limit is exceeded, sshd rejects the new channel request with an administrative prohibition, causing the client to see an immediate error such as channel 0: open failed: administratively prohibited: open failed.The client does not queue or retry the request; the calling program must handle the failure (e.g., open a new master or fall back to a non‑multiplexed session).Steps to guarantee a predictable upper boundDetermine the desired maximum number of multiplexed sessions per master (e.g., 8).Edit /etc/ssh/sshd_config (or a Match block) and set MaxSessions 8.Reload the SSH daemon: sudo systemctl reload sshd (or service sshd reload on SysV).Verify the setting: sshd -T | grep maxsessions should return maxsessions 8.Test with a master connection: ssh -M -S /tmp/ssh-mux-%h-%p-%r -fN user@host then open successive multiplexed sessions (ssh -S /tmp/ssh-mux-%h-%p-%r user@host true) until the limit is reached; the next attempt should fail with the administrative‑prohibition error.If you need to support more concurrent multiplexed sessions than a single master can handle, create additional master sockets by varying the ControlPath (e.g., include %r@%h:%p or a random identifier) so each master enforces its own MaxSessions limit independently.

SSH Connection Multiplexing: Unclear Upper Bound on Concurrent Sessions per Master

Goal

Constraints and Uncertainty

Unresolved Questions

1 answer

Answer

Confirmed facts

Steps to guarantee a predictable upper bound

Your perspective belongs here.

0 question comments