mosh vs SSH

SSH is an encrypted byte stream over one TCP connection: keystrokes go up it, the terminal’s output comes down it, and the connection is the session. When TCP dies — the laptop sleeps, the address changes from Wi-Fi to cellular, the train enters a tunnel — the session dies with it and the shell on the far end gets a hangup. ServerAliveInterval and ServerAliveCountMax in ssh_config decide how quickly the client notices; they don’t change the outcome. tmux or screen on the server keeps the process alive, but that is a second tool doing a job SSH doesn’t.

mosh keeps SSH for exactly one thing. The mosh command logs in over SSH, starts mosh-server as you, and the server “listens on a high UDP port and sends its port number and an AES-128 secret key back to the client over SSH.” Then SSH exits. From there client and server run the State Synchronization Protocol over UDP: instead of a stream of bytes, each side holds a picture of the terminal screen and they synchronise the difference, in datagrams encrypted with AES-128 in OCB mode, with a heartbeat at least every three seconds. Roaming falls out of the design — “every time the server receives an authentic packet from the client with a sequence number higher than any it has previously received, the IP source address of that packet becomes the server’s new target” — so sleeping the laptop, switching networks, and losing the link for an hour all resume without a reconnect.

The other half of mosh’s reputation is predictive local echo: the client models what the server will do with your keystrokes and shows the result before the round trip completes; on a bad link, “outstanding predictions are underlined so you won’t be misled.” --predict=adaptive is the default, always and never the alternatives, and Ctrl-^ . ends a session by force.

SSH needs one inbound TCP port, 22 by default. mosh needs that port for the login plus inbound UDP: “Mosh will use the first available UDP port, starting at 60001 and stopping at 60999”, and if you forward TCP 22 through a NAT you have to forward the UDP range too. mosh -p 60010 host pins the port; mosh --ssh="ssh -p 2222" host handles a non-standard SSH port. The symptom when UDP is blocked is precise — “Nothing received from the server on UDP port 60003” — meaning SSH worked and the datagrams aren’t getting through.

Both, then, need something listening on the host and a path in from outside: a public address, a port forward, or a VPN. Behind CGNAT or a sealed firewall, neither works without a third tool.

Put the two lists together and the gap is visible: SSH loses the session when the connection goes; mosh keeps the connection but loses scrollback and dies with the client; both need a port. What is left wanting is a session that lives on the host on purpose, with its history, reachable from whatever is in your hand, through a firewall that opens nothing.

That is the shape spawnd takes. One daemon per host you own, and it dials out — nothing listens, no UDP range, no VPN. A worker process on the host owns each session’s PTY, so a session survives the closed tab, the dropped connection, the laptop lid, and a daemon restart, scrollback intact. Any browser is the terminal; on a phone it installs to the home screen as a web app, with no keys on the device. Your browser talks to each daemon peer-to-peer, end-to-end encrypted, and the server that introduces them never sees session content. It has no predictive echo — on a truly bad link mosh still feels smoother, and on that link the older tool is the right one.