Does Mosh require root access or a daemon?

Updated

No. Mosh does not require superuser privileges and does not run a daemon. The client and server are ordinary executables run by your normal user account, and they exist only for the life of the connection. Mosh also does not listen on network ports or authenticate users itself — it logs in over SSH using the same credentials you already use.

What "no privileged code, no daemon" means in practice

Mosh's own documentation states this directly: you don't need to be the superuser to install or run Mosh, and the client and server are executables run by an ordinary user that last only for the life of the connection.

That gives you three concrete properties:

  • No root to install or run. You can install and use Mosh as a regular user. You are not adding a system service or changing how the machine boots.
  • Nothing stays running. There is no background process waiting for connections after you disconnect. When the session ends, the mosh processes end with it.
  • No new attack surface from listening ports. Mosh does not listen on network ports. It is not a server you expose and harden; it is a pair of short-lived processes tied to one session.

How login still works without its own authentication

Mosh deliberately does not implement its own authentication. The sequence is:

  1. The mosh client logs in to the server via SSH, using the same credentials as before — password, public key, or whatever your SSH setup uses.
  2. Once authenticated, Mosh starts mosh-server remotely.
  3. The client then connects to that server over UDP.

So your existing SSH trust model — keys, authorized_keys, sshd configuration — remains the gatekeeper. Mosh adds a UDP transport for the session itself, not a second login system.

What this means for your setup

Question Answer
Need root to install/run? No
Runs a persistent daemon? No
Listens on network ports? No
Authenticates users itself? No — SSH does
Credentials used Same as SSH (password, public key)
Process lifetime Only while the connection exists

A practical consequence: if SSH access already works for a user, that user is the right person to run Mosh. You don't need to grant elevated rights or open an additional inbound service just to get roaming and local echo. The trade-off is that Mosh depends on SSH being reachable for the initial login — it is a replacement for interactive SSH terminals, not a way to bypass SSH.

Where the UDP connection fits

Because the session runs over UDP rather than the SSH channel, Mosh can survive IP changes and dropped connectivity: the documentation describes automatic roaming between Wi-Fi, Ethernet, and cellular, and resuming after a laptop sleeps or the network drops. That robustness comes from the UDP protocol, while access control stays with SSH. If you are troubleshooting a connection, separate the two stages — SSH login first, then the UDP session — since a failure in either produces a different symptom.