Connection closed by remote host during SSH channel flow control exhaustion

The "Connection closed by remote host" error during large data transfers typically occurs because the sender transmits data faster than the receiver can process it, exhausting the SSH channel window. Under RFC 4254, SSH uses window-based flow control; if the sender's window reaches zero and the receiver fails to send an SSH_MSG_CHANNEL_ADJUST message, the connection stalls or eventually times out and is terminated by the peer.

Expected Behavior Across Implementations

The behavior varies significantly based on how the SSH library manages the window size:

• OpenSSH (e.g., v8.9+): Generally utilizes a static maximum window size (often 64KB per channel). On high-latency links (high BDP networks), this small window is insufficient to fill the pipe, as the sender constantly waits for acknowledgments, leading to throughput stalls.
• libssh (e.g., v0.10+): Provides application-level callbacks that allow for adaptive window adjustments. While this offers more flexibility, it is still dependent on the remote host to actively process data and signal available buffer space.

Steps to Mitigate Window Exhaustion

Since there is no standardized "automatic" window-scaling algorithm shared across all SSH implementations, you must manage the data rate or buffer overhead to prevent the remote peer from disconnecting:

1. Limit Sender Bandwidth: The most portable method to prevent the remote host from being overwhelmed is to throttle the transfer speed. This ensures the receiver can keep up with the data and send window adjustments regularly.

   scp -l 5000 local_file user@remote:/path/

2. Enable SSH Compression: Using the -C flag reduces the volume of data sent over the wire, which can prevent the window from filling up as quickly.

   scp -C local_file user@remote:/path/

3. Adjust TCP Keepalives: If the disconnection is caused by a timeout while the window is stalled, increasing keepalive intervals can help maintain the session.

   ssh -o ServerAliveInterval=15 -o ServerAliveCountMax=3 user@remote

Assumptions and Uncertainty

This analysis assumes the remote host has sufficient resources (CPU and I/O) to process the incoming stream. If the remote host is under extreme load, it may fail to send the SSH_MSG_CHANNEL_ADJUST messages entirely, leading to window exhaustion regardless of local client settings. To provide a more specific recommendation, could you confirm if the remote-side CPU usage or I/O wait spikes immediately before the disconnection, or if this occurs only on high-latency/satellite links?