3 SSH-Alternativen für instabile Verbindungen

Mosh, Eternal Terminal und autossh lösen dasselbe Problem auf drei unterschiedliche Arten: Mosh synchronisiert den Terminalzustand über UDP und folgt Ihnen über IP-Wechsel hinweg, Eternal Terminal stellt dieselbe Sitzung über TCP wieder her, und autossh startet SSH automatisch neu – allerdings jedes Mal mit einer frischen Sitzung.

Wer schon einmal ein Deployment mittendrin einfrieren sah, weil der Zug in einen Tunnel fuhr, kennt den weiteren Verlauf: Das Terminal blockiert, man wartet hoffnungsvoll, und eine Minute später starrt man auf client_loop: send disconnect. Café-WLAN, ein Handy-Hotspot und ein instabiles VPN richten mit einer Sitzung allesamt dasselbe an. Die Frage ist nicht, ob man einfaches SSH für interaktive Arbeit ersetzen sollte, sondern welches dieser drei Werkzeuge zu Ihrem Netzwerk und Ihrem Grad an Serverzugriff passt. Dieser Artikel vergleicht sie entlang einer einzigen Achse: Was passiert tatsächlich mit Ihrer Sitzung, wenn die Verbindung abreißt?

Was bricht, wenn die Verbindung abreißt?

Eine SSH-Sitzung lebt innerhalb einer einzelnen TCP-Verbindung, die an die IP-Adresse Ihres Clients gebunden ist. Fällt das Netzwerk aus oder ändert sich die Adresse, stirbt die Verbindung und nimmt die Remote-Shell mit. TCP identifiziert eine Verbindung über das Vier-Tupel aus Quell- und Zieladresse sowie Port; eine neue IP aus einem neuen WLAN bedeutet ein neues Tupel, von dem der Server noch nie gehört hat. Sobald Keepalives fehlschlagen oder der Socket einen Fehler wirft, räumt sshd die Shell und sämtliche darin laufenden Vordergrundprozesse ab. Die drei folgenden Werkzeuge setzen jeweils an einem anderen Glied dieser Kette an.

Mosh: Zustandssynchronisation über UDP

Verhalten im Fehlerfall

Mosh ersetzt das Byte-Stream-Modell durch Zustandssynchronisation: Client und Server halten jeweils einen Schnappschuss des Bildschirms, und Moshs State Synchronization Protocol führt beide über verschlüsselte UDP-Datagramme zusammen. Da der Server schlicht die Quelladresse des zuletzt authentifizierten Pakets adressiert, funktioniert das Roaming über IP-Wechsel hinweg automatisch: Laptop in den Ruhezustand versetzen, Netzwerk wechseln – und die Sitzung läuft ohne separaten Reconnect-Schritt weiter. Ein prädiktives lokales Echo zeigt Ihre Tastenanschläge sofort an, statt auf den Roundtrip zum Server zu warten.

Voraussetzungen

Mosh benötigt die Binärdatei mosh-server auf der Gegenstelle (ohne Superuser-Rechte und ohne dauerhaft laufenden Daemon: Beide Hälften laufen unter Ihrem Benutzerkonto und enden mit der Sitzung) sowie UDP-Erreichbarkeit. Mosh authentifiziert sich über einen normalen SSH-Login und nutzt anschließend standardmäßig einen UDP-Port im Bereich 60000 bis 61000 (den ersten freien Port ab 60001), den Firewalls durchlassen müssen. Optionen werden an das darunterliegende ssh durchgereicht:

mosh --ssh="ssh -i ~/.ssh/other_key" user@host

Wo es an Grenzen stößt

Ist UDP blockiert, funktioniert Mosh überhaupt nicht; einen TCP-Fallback gibt es nicht. Mosh hält zudem nur die aktuell auf dem Bildschirm sichtbaren Zeichen synchron, sodass Ihr Scrollback verloren geht – die FAQ des Projekts verweist Sie stattdessen auf screen oder tmux auf der Gegenseite. Der Vergleich der beiden Werkzeuge von Eternal Terminal ergänzt, dass Mosh den tmux-Control-Mode (tmux -CC) nicht ansteuern kann, was für iTerm2-Nutzer relevant ist. Die aktuellste Version auf der Releases-Seite des Projekts ist 1.4.0 vom Oktober 2022.

Eternal Terminal: Dieselbe Sitzung über TCP

Verhalten im Fehlerfall

Eternal Terminal nimmt die Verbindung über gewöhnliches TCP wieder auf, ohne abzureißen, woran Sie gerade gearbeitet haben – eine laufende tmux-Sitzung eingeschlossen. Ein Ausfall kostet Sie also eine Pause, nicht Ihre Arbeit. Da es TCP nie verlässt, funktioniert es genau in jenen Netzwerken, die Mosh ausschließen: Unternehmens-Firewalls, die UDP verwerfen, und Pfade, die den Verkehr zwingend über einen TCP-Proxy leiten.

Voraussetzungen

Eternal Terminal benötigt einen serverseitigen Daemon. Die README des Projekts nennt zwei Voraussetzungen: ssh übernimmt Handshake und Verschlüsselung, weshalb ssh user@hostname funktionieren muss, bevor ET funktioniert; und die Serverseite lauscht auf TCP-Port 2022, sofern Sie das nicht ändern. Installation unter macOS mit brew install et, unter Ubuntu:

sudo add-apt-repository ppa:jgmath2000/et
sudo apt-get update
sudo apt-get install et

Den Daemon prüfen Sie mit systemctl status et.

Wo es an Grenzen stößt

Wiederverbindung über TCP bedeutet: kein Roaming-Zauber und kein lokales Echo. Auf einer Verbindung mit hoher Latenz fühlt sich das Tippen weiterhin wie bei SSH an. Und da ein als root installierter Daemon sowie ein offener Port nötig sind, scheidet es auf Maschinen aus, auf denen Sie keine Software installieren dürfen.

autossh: Automatischer Neustart, frische Sitzung

Verhalten im Fehlerfall

autossh umhüllt ssh und überwacht den gestarteten Prozess; sobald dieser beendet wird oder verstummt, startet autossh einen Ersatz. Jede Wiederverbindung ist eine völlig neue SSH-Sitzung – ohne Multiplexer auf dem Server ist alles, was Sie gerade ausgeführt haben, verloren, sobald die Verbindung zurückkehrt.

Voraussetzungen

autossh benötigt auf dem Server nichts außer einem laufenden sshd, was es zur einzigen der drei Optionen auf Maschinen macht, auf denen Sie keine Software installieren können. Clientseitige Installation:

sudo apt install autossh   # Debian/Ubuntu
sudo dnf install autossh   # Fedora/RHEL family (may need EPEL)
brew install autossh       # macOS

Wo es an Grenzen stößt

Es stellt die Verbindung wieder her, nicht die Sitzung. Außerdem hängt es davon ab, dass ssh den Ausfall überhaupt bemerkt: Die Manpage empfiehlt ServerAliveInterval und ServerAliveCountMax, damit der Client schnell aufgibt, sobald die Verbindung tot ist.

tmux oder Zellij obendrauf

tmux und Zellij ersetzen keines dieser Werkzeuge: Sie halten Ihre Prozesse auf dem Server am Leben, während Mosh, Eternal Terminal und autossh Ihren Weg zum Server am Leben halten – beide Schichten ergänzen einander. Zellij ist ein Terminal-Multiplexer, der Sitzungen, Panes und Tabs verwaltet und sich genauso über eine Remote-Verbindung legt wie tmux.

autossh plus tmux ist das Minimum eines brauchbaren Setups, weil bei jedem Neustart eine persistente Sitzung wieder angebunden wird:

autossh -M 0 -o "ServerAliveInterval 10" -o "ServerAliveCountMax 3" \
  -t user@host "tmux new -A -s main"

-M 0 deaktiviert den Monitor-Port von autossh, sodass es sich auf das Beenden von ssh selbst verlässt, und tmux new -A -s main verbindet sich jedes Mal mit der Sitzung main (oder legt sie an). Die Kombination hilft auch den anderen: tmux liefert das Scrollback, das Mosh fehlt, und Eternal Terminal trägt eine tmux-Sitzung ausdrücklich durch Ausfälle hindurch.

Wie wählt man zwischen diesen SSH-Alternativen?

Stellen Sie drei Fragen in dieser Reihenfolge. Ist UDP zwischen Ihnen und dem Server blockiert? Falls ja, fällt Mosh weg; Eternal Terminal ist dann die robuste Wahl. Dürfen Sie auf dem Server etwas installieren? Falls nicht, bleibt Ihnen nur autossh plus tmux. Andernfalls entscheiden Sie nach Vorliebe: Mosh für Roaming und sofortiges Echo auf schlechten Verbindungen, Eternal Terminal, wenn Sie echtes Scrollback oder tmux -CC brauchen.

Der Fehlermodus, den Sie nicht tolerieren können, bestimmt das Werkzeug. Probieren Sie Mosh zuerst in einem offenen Netzwerk aus, behalten Sie Eternal Terminal für abgeschottete Umgebungen und legen Sie sich noch heute autossh -M 0 mit einer benannten tmux-Sitzung als Shell-Alias an; damit rüsten Sie jede Maschine auf, auf die Sie ohnehin schon per ssh zugreifen können.

FAQs

Funktioniert Mosh über einen SSH-Jump-Host oder Bastion-Server?

Nein. Mosh bietet keine eingebaute Unterstützung für [SSH-Tunnel oder Bastion-Hosts](https://docs.blink.sh/advanced/advanced-mosh). Ein Jump-Host kann den initialen SSH-Login transportieren, aber der verschlüsselte UDP-Verkehr muss die Zielmaschine anschließend direkt erreichen – und das leistet ein Jump-Server allein nicht. In Netzwerken, die ausschließlich über Bastion-Hosts erreichbar sind, funktioniert autossh unverändert, weil es gewöhnliches ssh ausführt, das ProxyJump unterstützt.

Ist Mosh genauso sicher wie einfaches SSH?

Der Login läuft weiterhin über SSH. Danach verschlüsselt und authentifiziert Mosh jedes UDP-Datagramm mit [AES-128 im OCB3-Modus](https://mosh.org/), einem Verfahren mit authentifizierter Verschlüsselung. SSH wird nur zum anfänglichen Schlüsselaustausch genutzt, sodass eine SSH-Schwachstelle diesen kurzen Aufbauschritt beträfe und nicht die langlaufende Mosh-Sitzung. Ihre bestehenden SSH-Schlüssel und die Host-Verifizierung gelten unverändert.

Kann autossh auch SSH-Portweiterleitungen am Leben halten und nicht nur interaktive Shells?

Ja, persistente Tunnel gehören zu den häufigsten Einsatzzwecken von autossh. Führen Sie es mit -N aus, damit kein Remote-Befehl ausgeführt wird, mit -M 0 zum Deaktivieren des Monitor-Ports und mit Ihren gewohnten -L- oder -R-Weiterleitungsoptionen; das Beispiel in der Manpage kombiniert -f -M 0 -N mit ServerAliveInterval und ServerAliveCountMax. Ein Tunnel hält keinen Shell-Zustand, weshalb die Einschränkung der frischen Sitzung hier nicht greift: autossh baut die Weiterleitung einfach neu auf.