Mosh-UDP-Ports 60000-61000: ufw-Regeln und mosh -p-Beispiele

Mosh benötigt die initiale SSH-Verbindung (standardmäßig TCP 22) plus einen UDP-Port pro Sitzung, der aus dem Bereich 60000 bis 61000 gewählt wird. Um nicht diesen gesamten Bereich freizugeben, legen Sie mit mosh -p 60000:60010 einen kurzen Bereich fest und erlauben nur diesen in ufw, iptables oder der Security Group Ihres Cloud-Anbieters.

Welche Ports Mosh nutzt: TCP für SSH, UDP 60000-61000 für die Sitzung

Mosh startet mosh-server über eine initiale SSH-Verbindung, und ab diesem Moment läuft die gesamte Sitzung über UDP. Auf dem Server sind also zwei getrennte Öffnungen nötig: der SSH-Port (bei OpenSSH standardmäßig TCP 22) und ein UDP-Port innerhalb des Bereichs 60000-61000.

Der Standardbereich umfasst 1001 Ports. Jeder mosh-server lauscht auf seinem eigenen Port, daher muss der Bereich nur die gleichzeitigen Sitzungen abdecken, die Sie auf dieser Maschine erwarten. Auf einem VPS, den Sie allein verwalten, sind das eine Handvoll Sitzungen, nicht tausend.

Wenn SSH funktioniert, die UDP-Pakete aber nie ankommen, wartet der Client einfach: Die Authentifizierung war erfolgreich, und das Terminal bleibt eingefroren. Das ist das klassische Symptom einer Firewall, die Port 22 durchlässt und den UDP-Bereich verwirft.

Den Mosh-UDP-Port mit mosh -p festlegen: ein Port oder ein kurzer Bereich

Die Client-Option -p (oder --port) teilt mosh-server mit, an welchen UDP-Port er sich binden soll oder in welchem Bereich er nach einem freien Port suchen soll, in der Form PORT oder PORT:PORT2. Ohne diese Option wählt Mosh einen Port zwischen 60000 und 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@server

Ein einzelner fester Port ist die restriktivste Variante, erlaubt aber nur eine Sitzung gleichzeitig: Eine zweite Verbindung mit demselben -p kann den Port nicht binden, solange die erste noch aktiv ist. Ein Bereich von elf Ports lässt Platz für mehrere Sitzungen und den einen oder anderen verwaisten mosh-server, ohne den ganzen Block zu öffnen. Die vollständige Syntax für Client und Server finden Sie in der offiziellen Mosh-Dokumentation.

ufw-Regeln für Mosh: warum 60000:61010/udp mehr öffnet als nötig

sudo ufw allow 60000:61010/udp wird von Tutorial zu Tutorial kopiert und öffnet zehn Ports über den Standardbereich von Mosh hinaus, der bei 61000 endet. Wenn Sie zusätzlich mit mosh -p einen Bereich festlegen, ist es konsequent, genau diesen Bereich zu öffnen und sonst nichts.

# 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 numbered

ufw verlangt beim Öffnen eines Portbereichs immer die Angabe eines Protokolls, deshalb enthält die Regel /udp. Bevor Sie ufw enable auf einem entfernten Rechner ausführen, prüfen Sie, ob die SSH-Regel aufgeführt ist: Ohne sie verlieren Sie auch die initiale Verbindung, die Mosh zum Starten von mosh-server braucht.

Mosh in Cloud-Security-Groups und mit iptables

Eine Cloud-Security-Group filtert, bevor das Paket die Maschine erreicht, während ufw oder iptables innerhalb der Maschine filtern: Mosh braucht den offenen UDP-Bereich auf beiden Ebenen. Wird nur eine geöffnet, entsteht dieselbe Sitzung, die sich authentifiziert und danach nie antwortet.

# 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/0

Die Quelle 0.0.0.0/0 ist Absicht: Ein Smartphone, das vom WLAN zu mobilen Daten wechselt, ändert seine IP-Adresse, und Mosh übernimmt die Sitzung von der neuen Adresse. Wer die Quelle auf die IP von Zuhause oder vom Büro beschränkt, macht genau diese Übergabe kaputt. Wenn der Server überhaupt keinen Internetverkehr annehmen darf, ist die Lösung ein privates Netzwerk, keine IP-Allowlist.

Mosh vs. SSH vs. Mesh-Netzwerke: was jede Option freigibt

Mosh bietet weder Port-Forwarding noch X11-Forwarding und ersetzt SSH daher nicht für -L- oder -R-Tunnel. Die Tabelle fasst zusammen, was jede Option auf dem Server öffnet und wie sie sich vom Smartphone aus verhält.

Mit einem privaten Mesh-Netzwerk ohne offene Ports wie Prialo oder mit Tailscale erreichen Sie Maschinen ohne öffentliche IP und ohne zum Internet geöffnete Ports; Mosh und SSH behalten ihre üblichen Ports, aber nur innerhalb dieses Netzwerks.

4 Fehler beim Öffnen von UDP-Ports für Mosh

1. 60000:61010 ungeprüft einfügen. Der Standardbereich von Mosh endet bei 61000; wenn Sie mit -p einen anderen festlegen, öffnen Sie genau diesen.
2. Nur eine Ebene öffnen. Eine ufw-Regel, aber keine Regel in der Security Group, oder umgekehrt: SSH kommt durch, UDP nicht.
3. Nach Quell-IP filtern. Das Smartphone ändert beim Wechsel zu mobilen Daten seine IP, und die Regel beendet genau die Sitzung, die Mosh am Leben gehalten hat.
4. Keine freien Ports mehr haben. mosh-server-Prozesse aus verlassenen Sitzungen belegen weiterhin Ports im Bereich. Finden Sie sie mit ss -ulpn | grep mosh-server und beenden Sie sie mit kill und ihrer PID.

Mosh unter iOS und Android mit termi1 nutzen

termi1 hält die Sitzung mit Mosh am Leben, wenn Sie vom WLAN zu mobilen Daten wechseln, und nutzt tmux, damit alles, was Sie laufen gelassen haben, bei Ihrer Rückkehr noch da ist; auf dem Server brauchen Sie nur die oben genannten Regeln. Die eigene Tastatur von termi1 hat Esc, Ctrl, Tab und Pfeiltasten, was beim Bearbeiten langer Regeln oder beim Verlassen einer seitenweise angezeigten ufw status-Ausgabe hilft, ohne mit der Systemtastatur zu kämpfen.

Die KI von termi1 verwandelt einen Satz wie „öffne die Mosh-UDP-Ports 60000 bis 60010 in ufw“ in den passenden Befehl und tippt ihn am Prompt ein, ohne Enter zu drücken, sodass Sie den Bereich vor dem Ausführen prüfen. Bei Verbindungen, die als Produktion markiert sind, hält Production Guard alles zurück, was den Zustand verändert, etwa eine Firewall-Regel, bevor es den Prompt erreicht. Die KI öffnet nie die Sitzung und erhält keine Schlüssel, und der private Schlüssel verlässt nie das Smartphone. Mehr zum mobilen SSH- und Mosh-Terminal.

Wenn der Server ein Mac ist, prüft termi1 Companion (macOS 14 oder neuer) vor dem Verbinden, ob Remote-Anmeldung, mosh-server und tmux verfügbar sind.

Häufig gestellte Fragen

Welche Ports muss ich für Mosh in der Firewall öffnen?

Mosh benötigt für die initiale Verbindung den TCP-Port von SSH, standardmäßig 22, und zusätzlich pro Sitzung einen UDP-Port im Bereich 60000-61000. Wenn Sie mit mosh -p einen Bereich festlegen, genügt es, genau diesen UDP-Bereich in der Firewall und in der Security Group zu öffnen.

Wie lege ich fest, welchen UDP-Port Mosh verwendet?

Der UDP-Port von Mosh wird mit der Client-Option -p oder --port festgelegt, zum Beispiel mosh -p 60001 user@server für einen festen Port oder mosh -p 60000:60010 für einen Bereich. mosh-server bindet den ersten freien Port innerhalb des angegebenen Bereichs.

Warum authentifiziert sich Mosh per SSH und hängt dann?

Mosh authentifiziert sich per SSH über TCP und wechselt danach zu UDP; friert das Terminal direkt nach der Authentifizierung ein, blockiert eine Firewall oder Security Group den UDP-Bereich. Prüfen Sie beide Ebenen und stellen Sie sicher, dass der geöffnete Bereich dem an mosh -p übergebenen entspricht.

Unterstützt Mosh Port-Forwarding wie SSH?

Mosh beherrscht weder Port-Forwarding noch X11-Forwarding. Für -L- oder -R-Tunnel brauchen Sie eine separate SSH-Verbindung oder ein privates Mesh-Netzwerk wie Prialo oder Tailscale, um den internen Dienst direkt zu erreichen, ohne dafür Ports zu öffnen.