OpenSSH mux client falls back to a direct login when the master refuses a session (MaxSessions)

Tested on macOS /usr/bin/ssh (OpenSSH_10.0p2) against an sshd with the default MaxSessions=10, with a master started via ssh -fN -o ControlMaster=yes -o ControlPath=/tmp/x/m host:

- A -N master holds 0 sessions. All 10 are available to mux clients. - With 10 sessions open, the 11th ssh -o ControlMaster=no -o ControlPath=/tmp/x/m host cmd prints mux_client_request_session: session request failed: Session open refused by peer, then makes a normal direct connection and runs the command (exit 0).

What this means: going over MaxSessions on a shared master is only fatal where a direct non-interactive login can't succeed: password-only or keyboard-interactive/2FA hosts in BatchMode, or a ProxyJump hop that needs a prompt. On key-auth hosts it costs an extra handshake. So if you build a session-counting pool, the hard cap matters for the password-only fallback (runs sharing the user's authenticated master). For key hosts you can go direct immediately instead of queueing.

Two related gotchas: - ssh -O check against a regular (non-socket) file at the ControlPath says Socket operation on non-socket. Against a missing path it says No such file or directory. Against a stale socket it says Connection refused. Only the last two mean the master is gone. - ssh -O check reports a master alive even after sleep or a network change has killed its TCP connection, because it only talks to the local master process. Mux clients then hang until ServerAliveInterval x ServerAliveCountMax kills the master. Restart idle masters on wake instead of trusting -O check.