Mosh needs the initial SSH connection (TCP 22 by default) plus one UDP port per session, picked from 60000 to 61000. To avoid exposing that whole range, pin a short range with mosh -p 60000:60010 and allow only that range in ufw, iptables or your cloud provider's security group.
Which ports Mosh uses: TCP for SSH, UDP 60000-61000 for the session
Mosh starts mosh-server over an initial SSH connection, and from then on the whole session runs over UDP. That means two separate openings on the server: the SSH port (TCP 22 by default in OpenSSH) and one UDP port inside the 60000-61000 range.
The default range is 1001 ports. Each mosh-server listens on its own port, so the range only has to cover the concurrent sessions you expect on that machine. On a VPS you administer alone, that is a handful of sessions, not a thousand.
When SSH works but UDP packets never arrive, the client just waits: authentication succeeded and the terminal stays frozen. That is the classic symptom of a firewall that lets port 22 through and drops the UDP range.
Pinning the Mosh UDP port with mosh -p: one port or a short range
The client's -p (or --port) option tells mosh-server which UDP port to bind, or which range to search for a free one, in the form PORT or PORT:PORT2. Without it, Mosh picks a port between 60000 and 61000.
# One specific UDP port
mosh -p 60001 user@server
# A short range: mosh-server takes the first free port
mosh -p 60000:60010 user@server
# SSH listening somewhere other than 22
mosh --ssh="ssh -p 2222" -p 60000:60010 user@serverA single fixed port is the tightest option, but it allows one session at a time: a second connection with the same -p cannot bind it while the first is still alive. A range of eleven ports leaves room for several sessions and the odd orphaned mosh-server without opening the whole block. The full client and server syntax lives in the official Mosh documentation.
ufw rules for Mosh: why 60000:61010/udp opens more than you need
sudo ufw allow 60000:61010/udp gets copied from tutorial to tutorial, and it opens ten ports beyond Mosh's default range, which ends at 61000. If you also pin a range with mosh -p, the consistent move is to open exactly that range and nothing else.
# SSH first, so enabling ufw does not lock you out
sudo ufw allow 22/tcp
# Only the range mosh -p will use
sudo ufw allow 60000:60010/udp
# Remove the wide rule if it is already there
sudo ufw delete allow 60000:61010/udp
sudo ufw enable
sudo ufw status numberedufw requires a protocol whenever you open a port range, which is why the rule carries /udp. Before running ufw enable on a remote box, confirm the SSH rule is listed: without it you also lose the initial connection Mosh needs to launch mosh-server.
Mosh in cloud security groups and with iptables
A cloud security group filters before the packet reaches the machine, while ufw or iptables filter inside it: Mosh needs the UDP range open in both layers. Opening only one produces the same session that authenticates and then never answers.
# iptables, on the server itself
sudo iptables -A INPUT -p udp --dport 60000:60010 -j ACCEPT
# AWS security group, via the CLI
aws ec2 authorize-security-group-ingress \
--group-id sg-0123456789abcdef0 \
--protocol udp --port 60000-60010 \
--cidr 0.0.0.0/0The 0.0.0.0/0 source is intentional: a phone moving from Wi-Fi to mobile data changes its IP address, and Mosh carries the session over from the new address. Restricting the source to your home or office IP breaks exactly that handover. If the server must not accept internet traffic at all, the answer is a private network, not an IP allowlist.
Mosh vs SSH vs mesh networks: what each option exposes
Mosh does no port forwarding and no X11 forwarding, so it does not replace SSH for -L or -R tunnels. The table sums up what each option opens on the server and how it behaves from a phone.
| Access method | Inbound ports on the server | Wi-Fi to mobile data switch | Port forwarding |
|---|---|---|---|
| SSH only | TCP 22 | Connection drops; tmux keeps running jobs | Yes, with -L and -R |
| Mosh, default range | TCP 22 and UDP 60000-61000 | Session carries on | No |
| Mosh with -p 60000:60010 | TCP 22 and UDP 60000-60010 | Session carries on | No |
| Private mesh network | None open to the internet | Mosh works the same inside the network | SSH's own, if you use it |
With a private mesh network, no open ports such as Prialo, or with Tailscale, you can reach machines with no public IP and no ports open to the internet; Mosh and SSH keep their usual ports, but only inside that network.
4 mistakes when opening UDP ports for Mosh
- Pasting 60000:61010 unchecked. Mosh's default range ends at 61000; if you pin another one with
-p, open exactly that. - Opening only one layer. A ufw rule but no security group rule, or the reverse: SSH gets in, UDP does not.
- Filtering by source IP. The phone changes IP when switching to mobile data, and the rule kills the session Mosh was keeping alive.
- Running out of free ports.
mosh-serverprocesses from abandoned sessions keep holding ports in the range. Find them withss -ulpn | grep mosh-serverand stop them withkilland their PID.
Using Mosh from iOS and Android with termi1
termi1 keeps the session alive with Mosh when you move from Wi-Fi to mobile data, and uses tmux so whatever you left running is still there when you come back; on the server, the rules above are all you need. termi1's own keyboard has Esc, Ctrl, Tab and arrow keys, which helps when editing long rules or leaving a paged ufw status without fighting the system keyboard.
termi1's AI turns a sentence like "open Mosh UDP ports 60000 to 60010 in ufw" into the command and types it at the prompt without pressing Enter, so you check the range before running it. On connections tagged as production, Production Guard holds back anything that changes state, such as a firewall rule, before it reaches the prompt. The AI never opens the session or receives keys, and the private key never leaves the phone. More on the mobile SSH and Mosh terminal.
If the server is a Mac, termi1 Companion (macOS 14 or later) checks that remote login, mosh-server and tmux are available before you connect.
Frequently asked questions
What ports does Mosh need open in the firewall?
Mosh needs the SSH TCP port, 22 by default, for the initial connection, plus one UDP port per session in the 60000-61000 range. If you pin a range with mosh -p, opening that UDP range in both the firewall and the security group is enough.
How do I tell Mosh which UDP port to use?
The Mosh UDP port is set with the client's -p or --port option, for example mosh -p 60001 user@server for a fixed port or mosh -p 60000:60010 for a range. mosh-server binds the first free port inside the given range.
Why does Mosh authenticate over SSH and then hang?
Mosh authenticates over SSH on TCP and then switches to UDP; if the terminal freezes right after authentication, a firewall or security group is blocking the UDP range. Check both layers and make sure the open range matches the one passed to mosh -p.
Does Mosh support port forwarding like SSH?
Mosh does not do port forwarding or X11 forwarding. For -L or -R tunnels you need a separate SSH connection, or a private mesh network such as Prialo or Tailscale to reach the internal service directly without opening ports.