ControlMaster multiplexing versus persistent keepalive reconnection for zero‑downtime SSH migration of a small application

Answer

When the underlying TCP session stays alive, ControlMaster multiplexing gives lower reconnection latency than a persistent keepalive‑reconnection approach (e.g., autossh).

Confirmed facts

• ControlMaster reuses an already‑authenticated SSH connection; opening a new channel over the master socket adds only a few milliseconds (no new TCP handshake or authentication).
• autossh detects a broken TCP session, then spawns a fresh ssh process, which requires a full TCP three‑way handshake and SSH authentication exchange, adding tens to hundreds of milliseconds of latency.
• Client‑side resource usage: ControlMaster keeps one long‑lived ssh client process plus a lightweight Unix‑domain socket per multiplexed session (minimal memory and file‑descriptor overhead). autossh adds a monitoring process that periodically exchanges keepalive packets and may restart ssh, consuming slightly more CPU and an extra file descriptor for the monitor.
• Server‑side load: Each multiplexed channel adds negligible overhead to the existing sshd daemon; each autossh‑triggered reconnection causes the server to fork a new sshd process and perform full authentication, increasing process count and auth load proportionally to the number of reconnections.

Likely explanation

Because ControlMaster avoids re‑authentication and the TCP handshake, its latency advantage is intrinsic to the multiplex design. autossh’s latency is dominated by the time needed to re‑establish the TCP session and complete SSH auth, which varies with network round‑trip time and server authentication method (e.g., password vs. key).

Steps for this case (small application, IP may change)

1. Enable ControlMaster in ~/.ssh/config for the target host:

   Host target
       ControlMaster auto
       ControlPath ~/.ssh/cm-%r@%h:%p
       ControlPersist 10m
       ServerAliveInterval 15
       ServerAliveCountMax 3
   

2. Start a long‑running master connection (e.g., ssh -Nf target) before launching the application.
3. Run the application via a multiplexed channel (e.g., ssh target ./myapp) or use ssh -O forward for port forwarding.
4. If the client IP changes, the TCP session breaks; the master connection drops. The application will see a brief interruption equal to the time needed to re‑establish the master connection (TCP handshake + auth). If this interruption is acceptable, no further action is needed.
5. If the interruption is not acceptable, consider a higher‑level mobility solution (VPN, NAT64, or application‑level reconnection) because neither ControlMaster nor autossh can survive an IP change without a new TCP session.

Operational overhead

• ControlMaster socket files: Must be cleaned after crashes or unclean exits; ControlPersist automatically removes the socket after the specified idle time, or you can manually delete stale sockets (rm ~/.ssh/cm-*).
• autossh keepalive loops: Requires tuning of AUTOSSH_POLL (monitoring interval) and SSH keepalive settings (ServerAliveInterval, ServerAliveCountMax) to avoid excessive reconnection bursts during network flaps.

Recommendation

For minimal reconnection latency and lower server load, prefer ControlMaster multiplexing, provided the application can tolerate the brief interruption when the client IP changes. If the application cannot tolerate any interruption, neither mechanism alone achieves zero‑downtime migration; a mobility layer (e.g., VPN) is required.

Missing diagnostic detail

What is the maximum tolerable interruption (in milliseconds) for your application? Knowing this threshold determines whether the brief reconnection latency of ControlMaster is acceptable or if a higher‑level mobility solution is mandatory.