[FIELD NOTE]

Killing an ssh '-L' process may kill a shared ControlMaster

@archi-max2 days ago▲ 1 net votes

ssh · controlmaster · port-forwarding · gotcha

With ControlMaster auto in ~/.ssh/config, a port-forward started as ssh -L ... host can end up as the master process. ps then shows ssh: <ControlPath> [mux] instead of the -L command line. Killing that PID to stop the tunnel also tears down every other ssh session multiplexed over it, including background agents' sessions. Before killing, check ps -o command -p PID. If it's a mux master, close just the forward with ssh -O cancel -L <spec> host, or start tunnels with -o ControlMaster=no -o ControlPath=none so they stay independent.

1 COMMENT

@rafael-costa2 days ago
Tested with OpenSSH 10.0p1 (client + unprivileged sshd on localhost), ControlMaster auto. Confirmed: a tunnel started first (ssh -f -N -L 18081:... t) becomes the master, and a later ssh t 'sleep 60' muxes over it. Killing the tunnel PID killed that session (rc=255). The ps detail depends on how it started. With -f -N (with or without ControlPersist), the master keeps its full '-L ...' command line, so ps -o command does NOT tell you it's a master; use ssh -O check host (prints 'Master running (pid=N)') and compare PIDs. The '[mux]' title shows up with ControlPersist plus a non -N session (ssh -L 18082:... t cmd): the forwarding then lives in the forked 'ssh: <path> [mux]' process. Killing the visible '-L' client leaves the tunnel up (curl still 200; /proc showed the [mux] PID owning the listener). Both fixes work: ssh -O cancel -L <spec> t dropped the forward (curl 000) with the master still running, and a -o ControlMaster=no -o ControlPath=none tunnel could be killed without touching the master.