PuTTY Network Error: Software Caused Connection Abort (How to Fix It)

What you're seeing

You logged in without trouble, worked for a while or walked away, and came back to a "PuTTY Fatal Error" dialog:

Network error: Software caused connection abort

The title bar may also show (inactive), which just means the session has ended; see PuTTY Inactive if that's the part you're chasing. The wording is the same on Windows 10 and Windows 11, and it appears for SSH and Telnet sessions alike.

Two variants point at the same family of problems and have the same fixes:

• Server unexpectedly closed network connection: the server side ended the connection, cleanly or not. Common when sshd restarts or the machine reboots.
• Network error: Connection reset by peer: something sent a TCP reset mid-session, often a firewall expiring your connection from its state table.

What this error is not: a failure to connect. If PuTTY errors the moment you hit Open, you're looking at Connection refused (active rejection) or Connection timed out (no answer at all) instead.

If you get the same behaviour from the OpenSSH command line (client_loop: send disconnect: Broken pipe), that's the identical problem in different clothes; SSH Broken Pipe is the client-agnostic walkthrough.

What's causing this error

A long-lived SSH session is a TCP connection that sits idle for minutes at a time. Everything in the path that tracks connections (your home router's NAT table, a corporate firewall, a VPN, a cloud load balancer) drops entries it considers stale, typically after 5 to 15 minutes of silence. The next time PuTTY tries to send anything over the dead socket, Windows reports the failure and PuTTY shows this error.

The real causes, in rough order of frequency:

1. NAT or firewall idle timeout. By far the most common. The session dies after a consistent period of not typing, and reconnecting works immediately.
2. Your local network changed. Laptop slept, Wi-Fi roamed to another access point, you docked and switched to Ethernet, or the VPN reconnected. The old socket is orphaned.
3. The server went away. Reboot, sshd restart during an upgrade, or an OOM kill on the server side.
4. Server-side idle policy. ClientAliveInterval/ClientAliveCountMax in sshd_config disconnects clients that stop responding.
5. Flaky link between you and the server. Weak Wi-Fi (a Raspberry Pi with wireless power saving is a classic), cellular tethering, long lossy routes.

How to fix it

Step 1: Turn on keepalives in PuTTY

This is the fix in most cases. Keepalives make PuTTY send a small packet at a fixed interval, so no device in the path ever sees the connection as idle.

1. Open PuTTY and load your saved session (Session panel → select it → Load).
2. Go to the Connection category.
3. Set Seconds between keepalives (0 to turn off) to 30.
4. Tick Enable TCP keepalives (SO_KEEPALIVE option) as well.
5. Go back to Session and click Save, then Open.

If you skip the Save, the change lasts one session and the problem "comes back". To apply it to every session, load Default Settings, make the same change, and save that.

The SSH-level keepalive (the seconds field) is the one that matters; TCP keepalives are a belt-and-braces extra that some aggressive firewalls ignore.

Step 2: Add a server-side keepalive

If you manage the server, make sshd keep the connection alive for every client, not just your copy of PuTTY. In /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

Set:

ClientAliveInterval 60
ClientAliveCountMax 3

Then restart sshd:

sudo systemctl restart ssh    # Debian/Ubuntu/Raspberry Pi OS
sudo systemctl restart sshd   # RHEL/CentOS/Fedora

The server now pings each client every 60 seconds and only disconnects after 3 missed replies (3 minutes of a genuinely dead link), instead of letting a NAT box decide.

Step 3: Run long jobs in tmux or screen

Keepalives make drops rare, not impossible. A dropped connection kills whatever was running in it, so anything long (backups, upgrades, builds) belongs in a terminal multiplexer that survives the disconnect:

# Start or attach:
tmux new -s work
# ...run your long job...
# After a disconnect, log back in and reattach:
tmux attach -t work

# Or with screen:
screen -S work
screen -r work

If the session drops, the job keeps running on the server and you reattach as if nothing happened.

Step 4: Stop your own machine from killing the link

If drops line up with the laptop lid, sleep, or moving between rooms:

• On Windows, stop the network adapter from powering down: Device Manager → your Wi-Fi/Ethernet adapter → Properties → Power Management → untick Allow the computer to turn off this device to save power.
• If you're on a VPN, note whether drops happen only while it's up. VPN reconnects orphan every open TCP connection; keepalives can't fix that, only a more stable VPN can.
• For a Raspberry Pi that you reach over its own Wi-Fi, turn off wireless power saving on the Pi:

iw dev wlan0 get power_save
sudo iw dev wlan0 set power_save off

Common edge cases