Session disconnects
What “Session disconnects” usually means
When PuTTY reports Session disconnects, the client has already attempted a network or protocol step and failed before a normal interactive shell is available. This guide explains what the message usually means on Windows clients, which local settings to verify first, and when the problem is almost certainly on the server, firewall, or DNS path rather than inside the PuTTY GUI.
Interactive sessions drop after working for a while. Distinct from immediate connect failures; focus on idle timers, NAT timeouts, and unstable networks.
Independent resource: Putty.info is educational only and is not affiliated with the official PuTTY project. Compare symptoms against the official documentation for your installed version.
Symptoms you will see
Operators usually notice this failure in one of a few repeatable ways. Capture the exact dialog text, the hostname and port from the Session panel, and whether the failure happens before or after a username prompt—those details decide which checklist below applies.
- Shell works, then freezes or drops after idle periods.
- Reconnects succeed until the next idle gap.
Likely causes ranked by frequency
Several independent conditions can produce the same client-facing wording. Work from the outside in: reachability first, protocol selection second, authentication third. Changing key files will not fix a TCP refusal, and opening a wider firewall will not fix a rejected public key.
- NAT/firewall idle timeouts.
- VPN sleep.
- Aggressive power management.
- Server ClientAlive killing idle users.
Step-by-step client checks
Use this ordered checklist on a workstation you control. Prefer saved sessions so Host Name, Port, and Connection type stay consistent while you isolate one variable at a time.
- Set seconds between keepalives in Connection (start modestly, e.g., 60) and test.
- Avoid zero keepalives on networks known to drop idle TCP.
- Keep VPN clients from auto-disconnecting.
- Compare with a second client path.
- Check whether only long-running tmux/screen sessions are needed server-side.
- See logging risks before enabling full session transcripts.
Do not paste private keys, passphrases, or production passwords into Putty.info tools or contact forms. Diagnose locally with PuTTY, Plink, PSCP, or PSFTP from an official install.
When it is a server or network issue
Align ClientAliveInterval with organizational idle policies. Document expected idle lifetime for jump hosts.
If TCP connects from another network path but fails from yours, involve the network team with traceroute/path evidence rather than repeatedly regenerating keys. If authentication fails after a banner appears, collect the server sshd logs for the same timestamp and username—client-side retries alone rarely reveal AccountLocked, Match blocks, or AllowUsers denials.
Field notes and runbook extras
Additional operational depth for Session disconnects (path /errors/session-disconnects/): treat every change to authentication, forwarding, or host-key storage as a reversible change under change control. Record the PuTTY version string from Help → About, the Windows build, and whether Pageant was running. Those three facts explain a surprising fraction of “it works on my laptop” discrepancies.
When documenting the procedure for teammates, include: the saved session name, Host Name and Port from the Session panel, whether Connection type is SSH, the username, whether a PPK path is set under Connection → SSH → Auth, and whether agent forwarding is enabled. Explicitly state that Putty.info is an independent educational site and that binaries must be obtained from the official project download page. Link readers to safe download guidance, host key verification, and the official manual so they can cross-check labels that differ slightly across releases.
If you still need more diagnostics after following the sections above, reproduce the issue with logging enabled under Session → Logging to a local file you control, scrub secrets from the transcript, and compare against server auth logs for the same UTC timestamp. Avoid third-party “PuTTY fix” utilities. Prefer updating to the current stable release from official hosts, re-importing a known-good saved session, and testing from a second network path before declaring the workstation broken.
- Keep private keys passphrase-protected and backed up offline according to your organization's secret-handling policy.
- Prefer named saved sessions over ad-hoc connections for anything beyond a one-off debug.
- Disable unused tunnels and agent forwarding by default; enable them per session only when required.
- Schedule periodic key rotation and remove stale authorized_keys entries during access reviews.
- Teach new operators the difference between connection errors and authentication errors before giving them production bastion access.