This error occurs when an SSH connection is unexpectedly terminated, typically due to network inactivity, firewall timeouts, or server disconnection. The connection breaks while attempting to send data to the remote host.
The "Broken pipe" error indicates that the SSH client tried to write data to the server, but the TCP connection was already closed or terminated by the remote host, a firewall, or a NAT device. This commonly happens when: 1. An idle SSH session times out after a period of inactivity 2. A firewall or NAT device automatically closes idle connections (typically after 5-30 minutes) 3. The SSH server terminates the connection due to its own timeout settings 4. Network interruption or unstable connection breaks the session 5. The remote server crashes or becomes unreachable The error name "packet_write_wait" refers to the SSH client attempting to send (write) a packet but finding the connection unavailable.
Edit your SSH config file to send periodic keep-alive packets to prevent timeouts.
For a single user, edit ~/.ssh/config:
Host *
ServerAliveInterval 60
ServerAliveCountMax 3For all users on the system, edit /etc/ssh/ssh_config:
Host *
ServerAliveInterval 60
ServerAliveCountMax 3Then try connecting again:
ssh user@hostnameThe ServerAliveInterval 60 sends a null packet every 60 seconds to keep the connection active. The ServerAliveCountMax 3 means the connection will be terminated if 3 consecutive keep-alive packets fail.
Some network configurations require the IPQoS (IP Quality of Service) option to be set. Add this to your ~/.ssh/config:
Host *
ServerAliveInterval 60
IPQoS=throughputAlternatively, use it on the command line:
ssh -o ServerAliveInterval=60 -o IPQoS=throughput user@hostnameThe IPQoS=throughput setting prioritizes data throughput over latency, which can help on networks with strict QoS policies.
If you have root access to the SSH server, configure the server to send keep-alive messages to clients.
Edit /etc/ssh/sshd_config on the server:
ClientAliveInterval 60
ClientAliveCountMax 3Then restart the SSH service:
# On systemd systems
sudo systemctl restart sshd
# On older systems
sudo service ssh restartThis tells the server to send keep-alive packets every 60 seconds to all connected clients, preventing idle disconnections.
Before permanently modifying config files, test the keep-alive settings from the command line:
ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=3 user@hostnameIf this resolves the issue, then add these options to your SSH config file (as shown in Step 1) to make them permanent.
You can also set it even more aggressively:
ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=5 user@hostnameIf the above solutions don't work, the issue may be network-related:
1. Check your firewall: Ensure port 22 (or your custom SSH port) is not being blocked by a firewall:
# Check local firewall (Linux)
sudo iptables -L
# or
sudo ufw status2. Test connectivity: Use a longer timeout to see if the connection initially works:
ssh -o ConnectTimeout=30 user@hostname3. Check server logs: On the server, check SSH logs for disconnection messages:
sudo tail -f /var/log/auth.log # Debian/Ubuntu
sudo tail -f /var/log/secure # CentOS/RHEL4. Test from a different network: If possible, try connecting from a different network or using a mobile hotspot to rule out local firewall/router issues.
For long-running operations, use screen or tmux to maintain your session even if SSH disconnects:
Using screen:
# Start a new screen session
screen -S mysession
# Run your long command
long-running-command
# Detach from screen (Ctrl+A, then D)
# Reconnect later
screen -r mysessionUsing tmux:
# Start a new tmux session
tmux new-session -s mysession
# Run your long command
long-running-command
# Detach from tmux (Ctrl+B, then D)
# Reconnect later
tmux attach-session -t mysessionThese terminal multiplexers keep your session alive on the server even if your SSH connection drops, so you can reconnect and resume without losing your work.
For extremely unreliable connections, consider using mosh (mobile shell) as an alternative to SSH. Mosh is designed to handle connection interruptions gracefully:
sudo apt install mosh # Install on server and client
mosh user@hostnameMosh automatically handles roaming between networks and inactivity timeouts much better than SSH.
On macOS, if you've recently upgraded to a newer version (like Mojave 10.14.1 or later), the broken pipe issue may be related to system-level TCP socket handling. Try updating OpenSSH:
brew upgrade opensshIf you're using Windows with the built-in OpenSSH that comes with recent versions, ensure you're running the latest build, as older versions had known broken pipe issues.
Load key "/home/user/.ssh/id_rsa": invalid format
How to fix 'Load key invalid format' in SSH
Bad owner or permissions on /home/user/.ssh/config
How to fix "Bad owner or permissions on .ssh/config" in SSH
Error connecting to agent: Connection refused
How to fix "Error connecting to agent: Connection refused" in SSH
Connection closed by UNKNOWN port 65535
How to fix 'Connection closed by UNKNOWN port 65535' in SSH
Offending ECDSA key in /home/user/.ssh/known_hosts:line
How to fix "Offending ECDSA key in known_hosts" in SSH