OpenSSH transport failure and remote command idempotency

When executing a non-idempotent command via OpenSSH, a network disconnection during the write phase can leave the remote process in an ambiguous state. Because the SSH protocol does not provide a built-in mechanism to track the completion status of a remote command after a transport-layer failure, the client cannot natively determine if the command was fully executed, partially executed, or never started.

While ServerAliveInterval and ServerAliveCountMax manage timeout detection, they do not facilitate the recovery of a session or the deduplication of writes. This creates a risk where external scripts wrapping SSH calls in retry loops may inadvertently trigger duplicate writes to the remote filesystem.

Technical Uncertainties

• Does the use of ControlMaster and ControlPersist alter the server-side process persistence when the primary transport connection is severed?
• Is there a documented method within the OpenSSH client to verify the exit status of a previously disconnected session without manual server-side auditing?