How to fix packet_write_wait: Connection to hostname port 22: Broken pipe in SSH

SSHINTERMEDIATEMEDIUMUpdated Jan 4, 2026· 285 views

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.

Quick fix

Fixes packet_write_wait: Connection to hostname port 22: Broken pipe

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
  1. Add ServerAliveInterval to SSH config (Client-side)
  2. Use IPQoS throughput option if ServerAliveInterval fails
  3. Configure server-side keep-alive (Server configuration)
  4. Temporarily test with command-line options
ssh — error
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
packet_write_wait: Connection to hostname port 22: Broken pipe

What this error means

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.

Typical symptoms

  • SSH connection drops after a period of inactivity (5-30 minutes)
  • Commands freeze or hang when not actively typing
  • Long-running operations fail mid-execution
  • Disconnection occurs even when actively using the terminal
  • Error appears specifically when trying to send data after idle time
  • Works initially but fails after some time in the session

Common causes

  1. Server-side idle timeout configured in /etc/ssh/sshd_config (ClientAliveInterval)
  2. Client-side settings not keeping the connection alive
  3. Firewall or NAT device dropping idle TCP connections
  4. Network router automatically closing long-idle connections
  5. SSH server has limited session duration settings
  6. Unstable or poor network connection
  7. Packet loss or network layer issues between client and server
  8. Remote server resource exhaustion or overload

How to fix "packet_write_wait: Connection to hostname port 22: Broken pipe"

1Add ServerAliveInterval to SSH config (Client-side)

Edit your SSH config file to send periodic keep-alive packets to prevent timeouts.

For a single user, edit ~/.ssh/config:

bash
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

For all users on the system, edit /etc/ssh/ssh_config:

bash
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

Then try connecting again:

bash
ssh user@hostname

The 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.

2Use IPQoS throughput option if ServerAliveInterval fails

Some network configurations require the IPQoS (IP Quality of Service) option to be set. Add this to your ~/.ssh/config:

bash
Host *
    ServerAliveInterval 60
    IPQoS=throughput

Alternatively, use it on the command line:

bash
ssh -o ServerAliveInterval=60 -o IPQoS=throughput user@hostname

The IPQoS=throughput setting prioritizes data throughput over latency, which can help on networks with strict QoS policies.

3Configure server-side keep-alive (Server configuration)

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:

bash
ClientAliveInterval 60
ClientAliveCountMax 3

Then restart the SSH service:

bash
# On systemd systems
sudo systemctl restart sshd

# On older systems
sudo service ssh restart

This tells the server to send keep-alive packets every 60 seconds to all connected clients, preventing idle disconnections.

4Temporarily test with command-line options

Before permanently modifying config files, test the keep-alive settings from the command line:

bash
ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=3 user@hostname

If 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:

bash
ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=5 user@hostname
5Check network and firewall configuration

If 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:

bash
# Check local firewall (Linux)
   sudo iptables -L
   # or
   sudo ufw status

2. Test connectivity: Use a longer timeout to see if the connection initially works:

bash
ssh -o ConnectTimeout=30 user@hostname

3. Check server logs: On the server, check SSH logs for disconnection messages:

bash
sudo tail -f /var/log/auth.log  # Debian/Ubuntu
   sudo tail -f /var/log/secure    # CentOS/RHEL

4. 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.

6Use screen or tmux for long-running sessions

For long-running operations, use screen or tmux to maintain your session even if SSH disconnects:

Using screen:

bash
# 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 mysession

Using tmux:

bash
# 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 mysession

These 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.

Advanced notes

For extremely unreliable connections, consider using mosh (mobile shell) as an alternative to SSH. Mosh is designed to handle connection interruptions gracefully:

bash
sudo apt install mosh  # Install on server and client
mosh user@hostname

Mosh 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:

bash
brew upgrade openssh

If 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.

Frequently asked questions

What does "packet_write_wait: Connection to hostname port 22: Broken pipe" mean?
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.
How do I fix "packet_write_wait: Connection to hostname port 22: Broken pipe"?
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.
What causes "packet_write_wait: Connection to hostname port 22: Broken pipe"?
Server-side idle timeout configured in /etc/ssh/sshd_config (ClientAliveInterval) Client-side settings not keeping the connection alive Firewall or NAT device dropping idle TCP connections
Is the "packet_write_wait: Connection to hostname port 22: Broken pipe" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading