Stopping PuTTY Session Timeouts with SSH Keep-alives

The Frustration of the Frozen Terminal

You are halfway through a complex database migration or a long-running log analysis on a remote server. You step away for a coffee, and when you return, your terminal is unresponsive. You type a command, hit enter, and nothing happens. Eventually, you see the dreaded Software caused connection abort or Connection timed out message.

This usually isn't a server crash. Instead, it is often a network intermediary—like a firewall, load balancer, or NAT (Network Address Translation) gateway that has silently dropped your idle TCP connection to save resources. To the server and your client, the connection looks open, but the "pipe" in the middle has been closed.

The solution is to implement SSH Keep-alives, which force PuTTY to send small, invisible packets to the server to prove the connection is still active.

How Keep-alives Prevent Silent Drops

TCP connections are designed to be efficient. If no data is sent for a specific period, many network devices assume the connection is dead and purge the session from their state table. When you finally try to send a keystroke, the firewall rejects the packet because it no longer recognizes the session.

PuTTY solves this through the "Seconds between keepalives" setting. When enabled, PuTTY sends a null packet (a packet that contains no application data) at a regular interval. This resets the idle timer on every network device between your machine and the server, effectively "pinging" the connection to keep it open without interfering with your actual shell session.

Configuring Keep-alives for Stability

To stop timeouts, you must configure the keep-alive interval before starting your session. These settings are found in the Connection category of the configuration tree.

Step-by-Step Configuration

1. Launch PuTTY.
2. In the Category pane on the left, navigate to Connection.
3. Locate the field labeled Seconds between keepalives (0 to turn off).
4. Enter a value. A common starting point is 60 seconds.
5. Return to the Session category, select your saved session name, and click Save to ensure you don't have to repeat this for every connection.

Practical Comparison: 60s vs. 300s

Choosing the interval depends on your network environment. Here is a comparison of common configurations:

Interval	Use Case	Network Impact	Risk
60 Seconds	Aggressive corporate firewalls or cloud gateways.	Negligible bandwidth usage.	Very low; standard for most environments.
300 Seconds	Stable internal LANs or permissive VPNs.	Minimal bandwidth usage.	May still be too slow for some aggressive NAT timeouts.
0 (Disabled)	Short-lived tasks or high-security servers.	No overhead.	High risk of session drop during inactivity.

Limitations and Trade-offs

While keep-alives solve idle timeouts, they are not a cure-all for network instability. It is important to understand what they cannot do:

• Physical Disconnects: If your Wi‑Fi drops or you change IP addresses (e.g., switching from Ethernet to Wi‑Fi), the TCP connection is severed. Keep-alives cannot reconnect a broken socket.
• Server-Side Timeouts: Some SSH servers are configured with ClientAliveInterval and ClientAliveCountMax. If the server is configured to kill sessions regardless of activity, client‑side keep-alives may not override the server's internal security policy.
• Security Monitoring: In extremely hardened environments, frequent null packets can be flagged by Intrusion Detection Systems (IDS) as abnormal behavior, though this is rare for standard 60‑second intervals.

Verifying the Connection

To verify that keep-alives are working, you can use a packet analyzer like Wireshark on your local machine. Filter for tcp.port == 22. Leave your terminal idle for a few minutes; you should see small TCP packets being sent from your IP to the server's IP at the exact interval you configured, even when you aren't typing.

If you still experience drops after setting a 60-second keep-alive, try lowering the value to 30 seconds to see if your network gateway has an exceptionally aggressive timeout policy.