SSH Broken Pipe: How to Fix It

What you're seeing

$ ssh [email protected]
... (you're working, you walk away for lunch, you come back) ...
client_loop: send disconnect: Broken pipe
$

Variants:

• packet_write_wait: Connection to X port 22: Broken pipe
• Write failed: Broken pipe
• Connection to X closed by remote host. (related, usually a server-side kill rather than NAT drop)

All point at the same underlying thing: a TCP connection that no longer works.

What's causing this error

A long-lived SSH session is a TCP connection that sits idle for minutes at a time. Anything in the path that holds connection state (your home router, a corporate firewall, your VPN, the cloud provider's load balancer) will drop "stale" connections to reclaim memory. Default timeouts are usually 5–15 minutes of total idleness.

When that happens, the next time you press a key, your client tries to write to a socket that's silently dead. The kernel raises EPIPE, which becomes "Broken pipe" in the error output.

The four sources, in rough order of likelihood:

1. NAT or firewall idle timeout. Most common. The connection table entry expired.
2. Your local network changed. Wi-Fi sleep, switching between Wi-Fi and Ethernet, VPN reconnect. The source IP changed, and the existing TCP socket is now orphaned.
3. Server-side ClientAliveInterval/ClientAliveCountMax explicitly disconnects idle sessions.
4. Network blip. Brief packet loss caused the connection to give up; rare on stable links but common over flaky cellular or distant hops.

How to fix it

Step 1: Add ServerAliveInterval to ~/.ssh/config

This is the fix in 90% of cases. Edit ~/.ssh/config:

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

What this does: every 60 seconds of idle time, your client sends a tiny encrypted keepalive to the server. The connection stays "active" from every NAT/firewall's perspective. ServerAliveCountMax 3 means "give up after 3 missed keepalives", so if the connection truly is dead, you find out after ~3 minutes instead of waiting indefinitely.

This applies to every host. If you only want it for specific hosts:

Host work.example.com
    ServerAliveInterval 60
    ServerAliveCountMax 3

Step 2: For sessions you can't afford to lose, use a multiplexer

ServerAliveInterval prevents drops. But for truly long-running work (a multi-hour build, an SSH session you started before lunch), you want the work to survive any disconnect, including ones you can't prevent.

Two options:

# tmux (recommended): start it on the server, detach safely.
$ ssh user@server
$ tmux new -s work
# Work happens. If the SSH session drops, the tmux session keeps running.
# Reconnect and re-attach:
$ ssh user@server
$ tmux attach -t work

Alternative: mosh, a UDP-based SSH replacement that survives IP changes and reconnects automatically. Worth it if you frequently switch networks.

Step 3: Server-side fix (only if you control the server)

If users keep getting kicked, you can tell sshd to send keepalives from its side:

# /etc/ssh/sshd_config
ClientAliveInterval 60
ClientAliveCountMax 3

Restart sshd:

sudo systemctl restart ssh

Now the server keeps the connection warm even for clients that don't set their own keepalive.

Common edge cases