Mosh vs SSH: Why Roaming Developers Should Use Both
You step onto the elevator, switch from wifi to LTE, and your SSH session dies. Mosh was built for exactly this: it survives IP changes, roaming, and short disconnects without dropping your shell. It's not a replacement for SSH — it's a companion. Here's when to reach for which.
Walk out of a coffee shop with an SSH session open. Your laptop switches from wifi to cellular. The connection holds for a few seconds, then dies. Your running editor is gone.
This isn't a bug in SSH. It's a design consequence. SSH uses TCP, and TCP sessions are tied to a specific IP address and port. When your IP changes, the old session becomes unreachable, and the server eventually hangs up.
Mosh (mobile shell) was written in 2012 by Keith Winstein as a direct answer to this problem. It uses UDP instead of TCP, and it doesn't care what your IP is. Roam between networks, close the lid, lose signal in a tunnel — your shell keeps running.
How Mosh Actually Works
The mechanism is clever:
- Mosh logs into your server over SSH first (so you reuse your existing key auth).
- It starts a
mosh-serverprocess on the remote host. - The client then speaks to that server over UDP, on a high port (typically 60000–61000).
- Mosh uses a state-synchronization protocol: the client and server agree on what the screen should look like, and re-sync automatically whenever a packet gets through.
The result: you can change networks, sleep your laptop for an hour, switch from airport wifi to hotel wifi, and the moment you reconnect, your terminal picks up exactly where it left off. No reconnect command, no re-authentication, no lost session.
It also handles latency gracefully. On high-latency links (think: ssh from China to a US server), local echo is instant — you see your keystrokes immediately, even if the server takes 300 ms to confirm.
The Tradeoffs
Mosh is not SSH, and it's not strictly better. Here's the honest comparison:
| Feature | SSH | Mosh |
|---|---|---|
| Roaming / IP change | No | Yes |
| Survives short disconnects | No | Yes |
| Local echo on latency | No | Yes |
Port forwarding ( -L / -D ) |
Yes | No |
File transfer (scp, sftp) |
Yes | No |
| Requires open UDP ports | No | Yes (60000–61000) |
| Works through strict firewalls | Yes (port 22) | Often no |
| Interactive shell | Yes | Yes |
| Copy-paste reliability | High | Good |
Mosh gives up two things you may need: port forwarding and file transfer. It's a shell, not a transport. If you need to tunnel a database port or pipe files back and forth, you still need SSH.
That's why the right answer is both: use Mosh for your interactive shell, use SSH (or rsync, or sftp) for everything else.
Installing Mosh
On the server:
# Debian / Ubuntu
sudo apt install mosh
# RHEL / Fedora
sudo dnf install mosh
# macOS (client)
brew install mosh
On the server, you need UDP traffic allowed on ports 60000–61000. If you run ufw:
sudo ufw allow 60000:61000/udp
If your server is behind a cloud firewall (AWS, GCP, Alibaba, Tencent), you'll need to open the same UDP range in the security group. This is the step people forget, and the #1 reason Mosh "doesn't work."
Using It
Once both ends are installed, it's as simple as:
mosh user@your-server
That's it. Mosh handles the initial SSH login, starts the server process, and transitions to its own UDP session. From that point on, you can close your laptop lid for hours and come back to the same shell.
If your SSH runs on a non-standard port:
mosh --ssh="ssh -p 2222" user@your-server
The Mosh + Tmux Combination
Mosh and tmux are natural partners, and they solve different problems:
- Mosh survives network changes.
- Tmux survives you disconnecting entirely.
Use Mosh for the transport layer. Use tmux for the session layer. Connect via mosh, start a named tmux session inside it, detach and reattach as needed. You now have a shell that survives:
- Your laptop changing networks
- Your laptop sleeping
- You closing the terminal app
- The mosh server restarting on the remote side
This is the setup many full-time remote developers settle on.
When to Stick With Plain SSH
Mosh is the wrong tool in a few situations:
- You need to forward ports. If you're tunneling a database, a Jupyter notebook, or a development server, you need SSH's
-Lor-D. Mosh has no equivalent. - You're behind a strict firewall. Corporate networks that allow only outbound TCP on port 443 will block Mosh's UDP traffic entirely.
- You're on a shared server you can't configure. If you can't install packages or open firewall ports, Mosh is unavailable.
- You need to transfer files. Mosh has no built-in file transfer. Pair it with sftp or rsync, which still run over SSH.
Mosh in FoxTerm
FoxTerm's SSH terminal is built on the Ghostty engine and supports standard PTY interactions, which means mosh works inside it. Install mosh on your server, open an SSH tab in FoxTerm, and run mosh user@localhost (or connect directly if you've configured your SSH config to invoke mosh). The integrated system-monitoring sidebar keeps showing you remote CPU, memory, and network metrics the whole time.
The Bottom Line
SSH isn't going anywhere. It's the universal protocol, it works through every firewall, and it handles everything Mosh can't. But if you work from a laptop that moves — coffee shops, trains, airports, hotels — Mosh removes the single most annoying thing about remote work: the dropped session.
Install both. Use Mosh when you're moving around. Use SSH when you're sitting still and need port forwarding or file transfer. You'll stop thinking about disconnects entirely.