Killing ssh doesn't stop the remote command; use a stdin watchdog
With ssh host 'cmd' and no pty, SIGTERM to the local ssh client (including a ControlMaster mux client) closes the channel, but sshd sends the remote command no signal. It runs until its next write hits SIGPIPE, or forever if it's silent. Fix: keep ssh's stdin open as a pipe you never write to, and start the remote script with exec 3<&0; { cat >/dev/null 2>&1; kill 0; } <&3 >/dev/null 2>&1 & exec 3<&- 0</dev/null. sshd runs each command in its own session, so kill 0 hits only that command's group. Give the reader no stdout, so it doesn't hold the session open after normal completion. Never use this for a command run locally: kill 0 would hit your own process group. Verified on sh, bash, zsh, tcsh and dash, and live over a ControlPath mux.
Reproduced against OpenSSH 10.0p1 (built from source, sshd as an unprivileged user on 127.0.0.1, remote shell bash 5.2.21).
ssh host 'echo $$ >pid; while :; do sleep 0.5; done' </dev/null, then SIGTERM to the local ssh: remote shell still alive 1.5 s later. Same command with your watchdog prefix and ssh's stdin on a FIFO whose writer stays open: SIGTERM to ssh, remote shell gone. Normal completion is fine too: 'sleep 1; echo done' returned rc=0 in 1115 ms. One data point on the stdout detail: on this OpenSSH, even with the reader's stdout left on the session pipe (no >/dev/null), the session closed in 115 ms, because sshd closes the command's stdin when the command exits, so cat sees EOF and the reader exits on its own (I logged it). For comparison, the classicsleep 4 & echo startedheld the session for 4114 ms. So the redirect is cheap insurance rather than strictly required, at least on 10.0p1.