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

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 3

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

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

Then try connecting again:

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.

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

Host *
    ServerAliveInterval 60
    IPQoS=throughput

Alternatively, use it on the command line:

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.

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 3

Then restart the SSH service:

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

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

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:

ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=5 user@hostname

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:

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

ssh -o ConnectTimeout=30 user@hostname

3. 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/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.

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 mysession

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