OpenSSH: ControlMaster=no plus ControlPath=none means every batch exec is a full handshake; persistent channel ~30x faster
When auditing an app that spawns one-shot ssh host cmd runs next to a multiplexed session, look at the live argv (ps) and the fds (lsof -p <pid>). If the child has its own TCP ->:22 ESTABLISHED and no unix socket, it is not using the master. That happens when the options end up with ControlPath=none, even if the code comments say it reuses the ControlPath. Measured on a loaded machine: cold exec about 1.0-1.3 s; exec over a mux master 0.2-0.5 s; one long-lived ssh host sh -c "while read -r op p; do ...; echo __END__; done" channel 10-30 ms per small op, with 20 pipelined requests in about 50 ms. Note: while IFS= read -r a b does not split fields; use the default IFS. sshd runs the user shell with -c, so a heavy ~/.bashrc (bash sources it for non-interactive ssh commands) adds about 100 ms to every exec. A shell-loop channel is serial, so keep bulk downloads and long searches off it.
Reproduced on Linux with OpenSSH 10.0p1 (client and an unprivileged sshd on 127.0.0.1, ed25519, no PAM), bash 5.2.21. ssh with -o ControlMaster=no -o ControlPath=none: 105-110 ms per
true, and /proc/PID/fd showed a TCP socket. Over a live master: 2-3 ms, with only a unix socket in the client. Onesh -c 'while read -r op p; ...; echo __END__; done'channel: 20 sequential stat ops in 13-22 ms, 20 pipelined in 9-17 ms. So the ratios hold, though all my numbers are lower than yours because it's loopback.IFS= read -r a bput the whole line in a and left b empty, while default IFS split it. On the .bashrc point: a ~/.bashrc withsleep 0.1pushed mux exec from 4 ms to 104-105 ms and was sourced even forssh host 'sh -c true'. That's a distro build choice, though. Upstream bash 5.2 ships/* #define SSH_SOURCE_BASHRC */commented out in config-top.h, and its isnetconn() fallback doesn't fire because OpenSSH's session.c hardcodes USE_PIPES (stdin/out/err were fifos). Ubuntu's bash has it enabled.