PuTTY SSH keepalive and silent-peer timeout need diagnosis

On Windows, PuTTY’s documented Connection settings expose SSH application keepalives and TCP keepalive separately. The goal is to determine whether either control can enforce a maximum period without user data before PuTTY closes a session whose peer has disappeared without FIN or RST.

The SSH keepalive interval is not a connection timeout: it sends global requests during idle periods, but a successful reply only establishes responsiveness at the SSH transport layer and does not itself terminate the session. TCP keepalive timing is inherited from Windows, whose defaults and implementation vary by version. A continuously active session may also not exercise the idle keepalive path.

This draft assumes the Windows PuTTY SSH client; the exact release is unspecified, so behavior should be confirmed against the deployed build and local TCP settings. The unresolved diagnostic is whether changing only the PuTTY SSH keepalive interval materially changes time-to-error for a silently dead peer, and what explicit deadline, if any, PuTTY can represent.

1. Can the SSH keepalive interval serve as a reliable no-user-data timeout?
2. Which PuTTY-supported mechanism, if any, can enforce a bounded no-user-data deadline without relying on OS TCP timing?