Remote side unexpectedly closed network connection
What “Remote side unexpectedly closed network connection” usually means
When PuTTY reports Remote side unexpectedly closed network connection, 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.
Network connection closed by the remote side unexpectedly—sibling wording to server-closed cases, emphasizing the transport drop.
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.
- Session ends with remote side closed messaging.
- Scripts using Plink see abrupt EOF.
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.
- Server or middlebox closed TCP.
- Idle timeouts without keepalive.
- Admin-initiated disconnects.
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.
- Enable modest keepalives under Connection if idle drops are suspected.
- Reproduce with logging to see last SSH message.
- Test stability on wired network.
- Confirm no duplicate NAT sessions colliding (less common).
- Coordinate with admins on idle policies.
- Ensure your remote command is not exiting in Plink one-shot mode when you expected interactive.
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
Review ClientAlive settings, load balancers with short idle timeouts, and deliberate disconnect tooling.
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 Remote side unexpectedly closed network connection (path /errors/remote-side-unexpectedly-closed/): 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.