Diagnosing PuTTY SSH Idle Disconnections with Keepalive Settings

Recognizable condition

When a PuTTY SSH session sits idle for a few minutes, the window may freeze or show an error such as “Server unexpectedly closed network connection” or “Software caused connection abort”. Typing resumes only after reconnecting. Actively used sessions stay connected, indicating the problem is tied to idle time, not authentication or host‑key issues.

Cause / diagnostic mapping

Observed symptom	Likely cause	What to look for
Freeze after ~2‑5 min idle, error on next keystroke	NAT/firewall or VPN dropping idle TCP state	Issue appears only behind a specific router/VPN; other networks work.
Clean disconnect after a fixed idle period (e.g. exactly 10 min)	Server‑side sshd idle timeout (ClientAliveInterval/ClientAliveCountMax)	Check /etc/ssh/sshd_config for ClientAlive*
No response until write times out (often >10 min)	Dead peer with keepalives disabled	Packet capture shows no traffic from either side.

Ordered checks

1. Note the exact error text and measure how long the session was idle before the failure.
2. Confirm that the drop correlates with inactivity by repeating the test with occasional keystrokes; if the session stays alive, the trigger is idle time.
3. Open PuTTY → Session → load your saved session → Connection category and record the current “Seconds between keepalives” value and the state of the “Enable TCP keepalives (SO_KEEPALIVE option)” checkbox.
4. Test the session from a different network (e.g., mobile hotspot) to see if the drop persists; this isolates client‑side or middlebox issues.
5. If you have administrative access to the server, inspect the SSH daemon configuration for ClientAliveInterval and ClientAliveCountMax to determine whether the server is terminating idle sessions.

Fixes tied to findings

• If the symptom matches a NAT/firewall idle timeout, set “Seconds between keepalives” to a value shorter than the shortest timeout in the path. A common starting point is 30–60 seconds. Leave TCP keepalives enabled as well.
• If the server‑side sshd policy is the cause, either ask the administrator to increase ClientAliveInterval or disable it, or adjust the client keepalive interval to be smaller than the server’s limit.
• After choosing values, return to the Connection category, enter the interval, tick the TCP keepalives box if desired, click Save under the session name, and close the dialog.
• Re‑open the saved session and verify that the Connection category still shows the values you entered.

Verification and limitations

To verify the fix, leave the session idle for the period that previously caused a drop (e.g., 4 minutes) with the new keepalive interval active. The session should remain responsive; if it still drops, increase the frequency (e.g., to 15 seconds) and repeat.

Keepalives only prevent idle‑time‑outs; they do not protect against network changes, laptop sleep/resume, Wi‑Fi roaming, or server restarts. Very frequent keepalives can keep a connection open through firewalls that administrators expect to timeout, so confirm the interval complies with local policy.

Escalation criteria

If drops continue even with keepalives set to 15 seconds, gather timestamps, the exact error text, and the network segment where the client resides and hand the case to the network or VPN team. Simultaneously verify:

• Server sshd idle settings (ClientAliveInterval/ClientAliveCountMax)
• Any middlebox or IDS session‑timeout rules
• Client‑side factors such as power‑saving modes, VPN re‑key events, or switch port‑security features.