Stop SSH sessions from disconnecting

The SSH broken pipe error means your client wrote to a connection that was already dead, either because something between you and the VM dropped an idle session or because the VM itself is gone, and a keepalive in ~/.ssh/config plus tmux for the job covers the first case.

client_loop: send disconnect: Broken pipe
Connection to 203.0.113.10 closed by remote host.
Timeout, server 203.0.113.10 not responding.
Read from remote host 203.0.113.10: Connection reset by peer

These four lines are copied from clientloop.c in the OpenSSH source, checked 12 November 2026. The first line is the wording in OpenSSH 8.0, and the 7.6 source prints packet_write_wait: Connection to 203.0.113.10 port 22: Broken pipe for the same step. The address is a documentation address, so read it as your VM.

What an SSH broken pipe means

The error is the symptom, not the cause. Broken pipe is the system's text for EPIPE, which the tcp(7) manual describes as "The other end closed the socket unexpectedly or a read is executed on a shut down socket." The send disconnect line comes from the last step of a session, when ssh tries to say goodbye and the write fails, so the connection had already died, sometimes minutes earlier. closed by remote host means the other side closed the connection, and Connection reset by peer is ECONNRESET, which the glibc manual describes as a connection "closed for reasons outside the control of the local host, such as by the remote machine rebooting or an unrecoverable protocol violation". Timeout, server ... not responding is your own keepalive giving up, covered below. A lone Connection to 203.0.113.10 closed. is a normal ending, because your remote shell exited.

First check whether the VM is still there

Reconnect with the same command. If it connects, the VM is fine and only the connection died. If it fails, read connection timed out or connection refused and look at the Deployments page.

A DeployGPU instance ends when you stop it, when its balance runs out or when the provider loses the machine. When the balance cannot cover the next hour, the instance runs on per-minute billing until the balance reaches zero, and then it is stopped and its disk deleted. Emails go out when about 2 hours of runtime are left, when per-minute billing starts and when the instance is stopped, and the Billing page shows Estimated time left. A machine that the provider loses is ended by the 5-minute health check with no email and disappears from the list.

If the VM answers, uptime -s prints when the system came up and last reboot lists the reboots, according to the uptime and last manuals. A restart ends every tmux session and every job.

Idle connections dropped on your side

A router, firewall or NAT device keeps a record of each connection and can forget one that stays quiet. RFC 5382 lets a NAT abandon an idle TCP session, says a conforming NAT must wait at least 2 hours 4 minutes for an established one, and says the timeouts may be configurable. TCP keepalive does not close the gap on Linux, because the tcp(7) manual says its probes start only after 7200 seconds of idle time by default.

SSH has its own keep alive, which works inside the protocol, and it is the fix I reach for first. The ssh_config manual says ServerAliveInterval is the seconds of silence after which ssh sends a message through the encrypted channel to request a response, with a default of 0 that sends nothing, and ServerAliveCountMax is how many such messages may go unanswered before ssh disconnects, with a default of 3. The manual's example of 15 seconds with the default count ends a dead connection after about 45 seconds, so 30 with 3 gives about 90. Put the block at the end of ~/.ssh/config, because the manual says the first value wins and general defaults belong at the end:

Host *
    ServerAliveInterval 30
    ServerAliveCountMax 3

For one connection, ssh -o ServerAliveInterval=30 ubuntu@203.0.113.10 does the same, and VS Code Remote-SSH reads the same file. A keepalive stops a session from looking idle. It cannot rescue a connection that is really down, and then ssh prints the Timeout, server line.

A laptop that sleeps or changes network

A sleeping laptop sends nothing, and a switch from Wi-Fi to a phone network changes your address. The Mosh README says Mosh keeps a session alive if the client sleeps and wakes up later, and lets the client roam between networks. It needs mosh-server on the VM and UDP between you and the VM, by default on ports 60000 to 61000, and it does not support port forwarding. DeployGPU does not document whether each provider passes that UDP traffic, so try it before you rely on it.

If a terminal is frozen after a wake-up, press Enter, then ~ and ., which the ssh manual lists as Disconnect when it follows a newline. Then reconnect and reattach to your tmux session.

Server-side settings

The server has the same pair of settings. The sshd_config manual says ClientAliveInterval makes sshd send a message after that many seconds without data from the client, with a default of 0 that sends nothing, and ClientAliveCountMax is how many may go unanswered before sshd disconnects the client, with a default of 3. That keeps a quiet session alive through a router, and it ends the session of a laptop that stops answering. The manual says a zero ClientAliveCountMax disables connection termination. When sshd drops a client it logs Timeout, client not responding from user ubuntu 198.51.100.7 port 51234, per serverloop.c, and sudo journalctl -u ssh.service shows it.

Ubuntu's OpenSSH documentation says the default configuration includes /etc/ssh/sshd_config.d/*.conf at the top, that the first value wins, and that you should run sudo sshd -t before restarting, because a mistake can lock you out of a server you reach only over SSH. Included files are processed in lexical order, so a snippet named to sort first wins:

ClientAliveInterval 60
ClientAliveCountMax 3

Save that as /etc/ssh/sshd_config.d/00-keepalive.conf, run sudo sshd -t, then sudo systemctl restart ssh.service, and keep your current session open until a second one connects. The shell can end an idle session too. The Bash manual says an interactive shell terminates when TMOUT is greater than zero and no complete line of input arrives within that many seconds. echo "$TMOUT" prints an empty line when it is not set.

Keep the job alive whatever the connection does

A job started in a plain SSH session stops when the connection ends, so run it in tmux and a dropped connection costs you only a reconnect:

tmux new -s train
tmux attach -t train

The keep jobs running guide covers tmux, nohup and systemd, and the port forwarding guide covers tunnels that drop. Nothing here keeps the instance itself alive. Stopping it, a zero balance and a lost machine all delete the disk, and the tmux session goes with it.

When to contact support

Contact support if the VM is listed, reconnecting works, and sessions still die within minutes with ServerAliveInterval set and no server-side timeout in place. Email support@deploygpu.ai with the times of the last two drops and your time zone, the exact lines ssh printed, the provider, the deployment ID and the output of last reboot. The contact page is the other way in, and the SSH guide covers keys and config files.