3 SSH Alternatives for Unstable Connections

Mosh, Eternal Terminal, and autossh solve the same failure in three different ways: Mosh synchronizes terminal state over UDP and follows you across IP changes, Eternal Terminal reconnects the same session over TCP, and autossh restarts SSH automatically but starts a fresh session each time.

If you have ever watched a deploy freeze halfway through because your train went into a tunnel, you know how the rest of it goes: the terminal locks up, you sit there hoping, and a minute later you are staring at client_loop: send disconnect. Café Wi-Fi, a tethered phone, and a flaky VPN all do the same thing to a session. The question is not whether to replace plain SSH for interactive work; it is which of these three tools fits your network and your level of server access. This article compares them on one axis: what actually happens to your session when the link fails.

What Breaks When the Link Drops?

An SSH session lives inside a single TCP connection tied to your client’s IP address, so when the network drops or the address changes, the connection dies and takes the remote shell with it. TCP identifies a connection by the four-tuple of source and destination address and port; a new IP from a new Wi-Fi network means a new tuple that the server has never heard of. Once keepalives fail or the socket errors out, sshd reaps the shell and every foreground process in it. The three tools below each attack a different link in that chain.

Mosh: State Synchronization Over UDP

What It Does on Failure

Mosh replaces the byte-stream model with state synchronization: client and server each hold a snapshot of the screen, and Mosh’s State Synchronization Protocol converges them over encrypted UDP datagrams. Because the server simply targets the source address of the latest authenticated packet, roaming across IP changes is automatic; sleep the laptop, switch networks, and the session resumes without any reconnect step. Predictive local echo shows your keystrokes immediately instead of waiting for the server round trip.

What It Requires

Mosh requires the mosh-server binary on the remote machine (no superuser rights and no long-running daemon: both halves run as you and stop when the session does), plus UDP reachability. Mosh authenticates over a normal SSH login, then by default uses a UDP port in the 60000 to 61000 range (the first available port from 60001 up), which firewalls must allow. It passes options through to the underlying ssh:

mosh --ssh="ssh -i ~/.ssh/other_key" user@host

Where It Falls Short

If UDP is blocked, Mosh does not work at all; there is no TCP fallback. Mosh also keeps only the characters currently on screen in sync, so your scrollback is gone, and the project’s own FAQ points you at screen or tmux on the far end instead. Eternal Terminal’s comparison of the two tools adds that Mosh cannot drive tmux control mode (tmux -CC), which matters to iTerm2 users. The newest version on the project’s releases page is 1.4.0, from October 2022.

Eternal Terminal: The Same Session Over TCP

What It Does on Failure

Eternal Terminal picks the connection back up over ordinary TCP without tearing down what you were doing, a running tmux session included, so an outage costs you a pause rather than your work. Because it never leaves TCP, it works on exactly the networks that rule Mosh out: corporate firewalls that drop UDP, and paths that force traffic through a TCP proxy.

What It Requires

Eternal Terminal requires a server-side daemon. The project README sets out two prerequisites: ssh does the handshake and the encryption, so ssh user@hostname has to work before ET will, and the server side listens on TCP port 2022 unless you change it. Install with brew install et on macOS, or on Ubuntu:

sudo add-apt-repository ppa:jgmath2000/et
sudo apt-get update
sudo apt-get install et

Check the daemon with systemctl status et.

Where It Falls Short

Reconnection over TCP means no roaming magic and no local echo: on a high-latency link, typing still feels like SSH. And because it needs a root-installed daemon and an open port, it is off the table on boxes where you cannot install software.

autossh: Automatic Restart, Fresh Session

What It Does on Failure

autossh wraps ssh and watches the process it launched, starting a replacement whenever that process quits or goes silent. Every reconnection is a brand-new SSH session, so without a multiplexer on the server, whatever you were running is gone when the link comes back.

What It Requires

autossh requires nothing on the server beyond a running sshd, which makes it the only option of the three on machines where you cannot install software. Client-side install:

sudo apt install autossh   # Debian/Ubuntu
sudo dnf install autossh   # Fedora/RHEL family (may need EPEL)
brew install autossh       # macOS

Where It Falls Short

It restores the connection, not the session. It also depends on ssh noticing the failure: the man page suggests ServerAliveInterval and ServerAliveCountMax so the client gives up quickly once the link is dead.

tmux or Zellij on Top

tmux and Zellij do not replace any of these tools: they keep your processes alive on the server, while Mosh, Eternal Terminal, and autossh keep your path to the server alive, and the two layers combine. Zellij is a terminal multiplexer that manages sessions, panes, and tabs and layers over a remote connection the same way tmux does.

autossh plus tmux is the minimum workable setup, because it reattaches a persistent session on every restart:

autossh -M 0 -o "ServerAliveInterval 10" -o "ServerAliveCountMax 3" \
  -t user@host "tmux new -A -s main"

-M 0 disables autossh’s monitor port so it relies on ssh’s own exit, and tmux new -A -s main attaches to (or creates) the main session each time. The pairing helps the others too: tmux supplies the scrollback Mosh lacks, and Eternal Terminal explicitly carries a tmux session through outages.

How Do You Choose Among These SSH Alternatives?

Ask three questions in order. Is UDP blocked between you and the server? If yes, Mosh is out; Eternal Terminal is the resilient choice. Can you install anything on the server? If not, autossh plus tmux is your only move. Otherwise, pick by feel: Mosh for roaming and instant echo on bad links, Eternal Terminal if you need real scrollback or tmux -CC.

The failure mode you cannot tolerate picks the tool. Try Mosh first on an open network, keep Eternal Terminal for locked-down ones, and put autossh -M 0 with a named tmux session in a shell alias today; it upgrades every box you can already ssh into.

FAQs

Does Mosh work through an SSH jump host or bastion?

No. Mosh has no built-in handling of [SSH tunnels or bastion hosts](https://docs.blink.sh/advanced/advanced-mosh). A jump host can carry the initial SSH login, but the encrypted UDP traffic has to reach the target machine directly afterwards, which a jump server on its own does not give you. On bastion-only networks, autossh works unchanged because it runs ordinary ssh, which supports ProxyJump.

Is Mosh as secure as plain SSH?

Login still runs over SSH. After that, Mosh encrypts and authenticates every UDP datagram with [AES-128 in OCB3 mode](https://mosh.org/), an authenticated encryption scheme. SSH is used only to exchange the keys at the start, so an SSH weakness would touch that brief setup step rather than the long-running Mosh session. Your existing SSH keys and host verification apply unchanged.

Can autossh keep SSH port forwards alive, not just interactive shells?

Yes, persistent tunnels are one of autossh's most common uses. Run it with -N so no remote command executes, -M 0 to disable the monitor port, and your usual -L or -R forwarding flags; the man page's own example combines -f -M 0 -N with ServerAliveInterval and ServerAliveCountMax. A tunnel holds no shell state, so the fresh-session limitation does not apply: autossh simply re-establishes the forward.