Mosh

Q: Wer hat Mosh geschrieben?

Mosh wurde von Keith Winstein geschrieben, zusammen mit Anders Kaseorg, Quentin Smith, Richard Tibbetts, Keegan McAllister und John Hood.

F: Warum ein weiteres Remote-Terminal-Protokoll?

Praktische Latenzzeiten im Internet nehmen mit dem Aufkommen von Bufferbloat und ausgeklügelten drahtlosen Verbindungen, die den Durchsatz gegenüber der Verzögerung optimieren, immer mehr zu. Und Roaming ist heute üblicher denn je, da Laptops und Handheld-Geräte die Desktops weitgehend verdrängt haben. SSH ist großartig, aber frustrierend, wenn man IP-Adressen ändern will oder eine Verbindung mit langer Verzögerung oder eine zweifelhafte Verbindung hat.

Außerdem hatte TELNET einige gute Seiten – einen lokalen Echo-Modus und ein gut definiertes virtuelles Netzwerkterminal. Selbst heute noch unterstützt SSH UTF-8 nicht durchgängig auf einem POSIX-System.

F: Sind die Mosh-Prinzipien auch für andere Netzwerkanwendungen relevant?

Wir denken ja. Die Design-Prinzipien, für die Mosh steht, sind konservativ: Warnung des Benutzers, wenn der angezeigte Status veraltet ist, Serialisierung und Checkpointing aller Transaktionen, so dass der Benutzer weiß, dass jede vorherige Transaktion erfolgreich war, wenn es keine Warnungen gibt, und eleganter Umgang mit erwarteten Ereignissen (wie Roaming von einem WiFi-Netzwerk zu einem anderen).

Diese scheinen nicht allzu kontrovers zu sein, aber ausgefallene Anwendungen wie Gmail-in-Chromium oder auf Android verhalten sich immer noch grauenhaft bei zweifelhaften Verbindungen oder nach dem Wechsel der IP-Adresse. (Haben Sie schon einmal erlebt, dass Gmail eine E-Mail-Nachricht zehn Stunden lang in „Sending…“ belassen hat, während es fröhlich neue E-Mails abruft und keinerlei Fehler anzeigt? Wir auch.) Wir glauben, dass die Anwendung dieser Werte in vielen Netzwerk-Benutzeroberflächen ein erhebliches Verbesserungspotenzial birgt.

F: Ich erhalte die Meldung „mosh erfordert ein UTF-8 Gebietsschema.“ Wie kann ich das beheben?

Um das Problem zu diagnostizieren, führen Sie locale auf dem lokalen Terminal und ssh remotehost locale aus. Um Mosh zu benutzen, müssen beide Seiten der Verbindung ein UTF-8 Gebietsschema anzeigen, wie z.B. LC_CTYPE="en_US.UTF-8".

Auf vielen Systemen überträgt SSH die ortsbezogenen Umgebungsvariablen, die dann von mosh-server geerbt werden. Wenn dieser Mechanismus fehlschlägt, wird Mosh (ab Version 1.2) die Variablen selbst übergeben. Wenn keiner der beiden Mechanismen erfolgreich ist, können Sie etwas tun wie

mosh remotehost --server="LANG=en_US.UTF-8 mosh-server"

Wenn en_US.UTF-8 auf dem entfernten Server nicht existiert, können Sie es durch ein UTF-8 Gebietsschema ersetzen, das es gibt. Möglicherweise müssen Sie auch LANG lokal einstellen, um mosh-client zu nutzen. Es ist möglich, dass der lokale und der entfernte Rechner unterschiedliche Locale-Namen benötigen. Siehe auch dieses GitHub-Ticket.

F: Was bedeutet die Meldung „Nothing received from the server on UDP port 60003“?

Das bedeutet, dass mosh mosh-server erfolgreich auf dem entfernten Rechner starten konnte, aber der Client nicht mit dem Server kommunizieren kann. Dies bedeutet im Allgemeinen, dass eine Art Firewall die UDP-Pakete zwischen Client und Server blockiert. Wenn Sie den TCP-Port 22 auf einem NAT für SSH weiterleiten mussten, dann müssen Sie auch die UDP-Ports weiterleiten. Mosh verwendet den ersten verfügbaren UDP-Port, beginnend mit 60001 und endend mit 60999. Wenn Sie nur eine kleine Anzahl gleichzeitiger Sitzungen auf einem Server haben, können Sie einen kleineren Bereich von Ports weiterleiten (z. B. 60000 bis 60010).

Tools wie netstat, netcat, socat und tcpdump können für die Fehlersuche bei Netzwerk- und Firewall-Problemen nützlich sein.

Dieses Problem kann auch das Ergebnis eines Fehlers in glibc 2.22 sein, der Programme betrifft, die mit protobuf und utempter linken und aggressive Compiler-Hardening-Flags verwenden. (Glibc-Bugtracker-Eintrag, sowie Mosh-Bugtracker-Eintrag.) Das Problem führt dazu, dass mosh-server sofort beim Start einen Segfault verursacht. Wir glauben, dass wir dieses Problem in Mosh 1.2.6 umgangen haben, aber bitte melden Sie einen Fehler, wenn Sie etwas anderes feststellen.

F: Warum bestehen Sie überall auf UTF-8?

Wir sind wirklich keine UTF-8-Eiferer. Aber es ist viel einfacher, einen Terminalemulator korrekt zu implementieren, als zu versuchen, das Richtige in einer Vielzahl von schwierigen Randfällen zu tun. (Das ist es, was GNU screen zu tun versucht, und unserer Erfahrung nach führt es zu einigen sehr kniffligen Situationen beim Debuggen). Also wird mosh einfach nicht starten, bis der Benutzer alles für einen UTF-8-sauberen Pfad konfiguriert hat. Das mag ärgerlich sein, aber es reduziert wahrscheinlich auch die Frustration auf dem Weg dorthin. (Unglücklicherweise sind ein 8-Bit vt220 und ein UTF-8 vt220 unterschiedliche und inkompatible Terminaltypen; das UTF-8 wird unterhalb der vt220-Zustandsmaschine eingesetzt.)

F: Wie kann ich einen anderen SSH-Port (nicht 22) verwenden?

Ab Mosh 1.2 können Sie ssh Argumente wie folgt übergeben:

mosh remotehost --ssh="ssh -p 2222"

Oder Sie konfigurieren einen Host-Alias in ~/.ssh/config mit einer Port Direktive. Mosh wird auch das respektieren.

Q: Ich bekomme ‚mosh-server not found‘.

Bitte vergewissern Sie sich, dass mosh auf dem Client und mosh (oder zumindest mosh-server) auf dem Server, mit dem Sie sich verbinden wollen, installiert ist. Außerdem wird erwartet, dass der Server unter dem Standard-Login PATH des Servers verfügbar ist, was auf OS X- und BSD-Servern normalerweise nicht der Fall ist, oder wenn Sie mosh-server in Ihrem Heimatverzeichnis installieren. In diesen Fällen beachten Sie bitte die Anweisungen „Server-Binary außerhalb des Pfades“ im Abschnitt Verwendung, oben.

F: SSH authentifiziert sich mit Kerberos-Tickets, aber Mosh fragt mich nach einem Passwort.

In einigen Konfigurationen kanonisiert SSH den Hostnamen, bevor es ihn an das Kerberos-GSSAPI-Plugin weitergibt. Dies führt bei Mosh zu Problemen, da der anfängliche Forward-DNS-Lookup durch das Mosh-Wrapper-Skript durchgeführt wird. Um dies zu umgehen, rufen Sie Mosh als

mosh remotehost --ssh="ssh -o GSSAPITrustDns=no"

auf. Dies wird bei einem Round-Robin-DNS-Setup oft fehlschlagen. In diesem Fall ist es wahrscheinlich am besten, einen bestimmten Host aus dem Round-Robin-Pool zu wählen.

F: Warum ist der Scrollback-Puffer meines Terminals unvollständig?

Mosh synchronisiert nur den sichtbaren Status des Terminals. Wir verfolgen dieses Problem; siehe dieses Problem und die anderen, die von dort aus verlinkt sind. Im Moment besteht die Abhilfe darin, screen oder tmux auf der entfernten Seite zu verwenden.

F: Wie bekomme ich 256 Farben?

Stellen Sie sicher, dass Sie mosh in einem Terminal laufen lassen, das sich selbst als 256-Farben-fähig ankündigt. (Das bedeutet im Allgemeinen, dass TERM xterm-256color oder screen-256color-bce ist.)

F: Wie tippe ich C-^, das Standard-Escape-Zeichen von Mosh?

Auf Tastaturen mit US-amerikanischem Layout kann es als Strg-Umschalt-6 oder oft als Strg-6 eingegeben werden (dies hängt von Ihrem Betriebssystem und Terminalemulator ab). Auf nicht-amerikanischen Tastaturen ist es oft schwierig, die richtige Taste zu finden, und manchmal ist sie überhaupt nicht verfügbar. Wenn Ihre Tastatur eine tote Taste mit einem Akzent-Zirkumflex hat, ist dies wahrscheinlich nicht die richtige Taste. Strg-6 funktioniert jedoch manchmal. Wenn Sie nicht in der Lage sind, dieses Zeichen zu tippen, müssen Sie die Variable MOSH_ESCAPE_KEY setzen; siehe die Mosh-Manpage für Details.

F: Wie kann ich den Server dazu bringen, ruhende Sitzungen automatisch zu löschen?

Bitte lesen Sie die Einträge für MOSH_SERVER_NETWORK_TMOUT und MOSH_SERVER_SIGNAL_TMOUT in der mosh-server(1) man page.

F: Wie ist die bisherige Sicherheitsbilanz von Mosh?

Mosh 1.0 wurde im März 2012 veröffentlicht. Seit der Veröffentlichung von Mosh 1.3.2 im Juli 2017, soweit den Entwicklern bekannt ist:

• In den letzten vier Jahren wurden in Mosh keine Sicherheitslücken irgendeiner Art (größere oder kleinere) gemeldet.
• Es wurden nie größere Sicherheitslücken in Mosh gemeldet. Wir definieren größere Sicherheitsschwachstellen als Privilegienerweiterung, Remotecodeausführung, Denial-of-Service durch Dritte usw.
• Zwei Denial-of-Service-Probleme wurden in den Versionen von 2012 entdeckt und behoben. Ein Problem ermöglichte es einem Mosh-Server, den Mosh-Client zu einer übermäßigen CPU-Auslastung zu veranlassen (CVE-2012-2385, behoben in Mosh1.2.1, veröffentlicht im Mai 2012). Ein anderes Problem ermöglichte es dem Serverhost, den mosh-Client dazu zu bringen, UDP-Datagramme an eine falsche Adresse zu senden, wodurch sein Verbindungsversuch vereitelt wurde (behoben inMosh 1.2.3, veröffentlicht im Oktober 2012).

F: Wie steht es um die Sicherheit von Mosh im Vergleich zu SSH?

Wir denken, dass das konservative Design von Mosh bedeutet, dass seine Angriffsfläche im Vergleich zu komplizierteren Systemen wie OpenSSL und OpenSSH günstig ist. Die Erfolgsbilanz von Mosh hat dies bisher bestätigt. Letztendlich wird jedoch nur die Zeit zeigen, wann die erste ernsthafte Sicherheitslücke in Mosh entdeckt wird – entweder weil sie von Anfang an vorhanden war oder weil sie versehentlich während der Entwicklung hinzugefügt wurde. OpenSSH und OpenSSL hatten mehr Schwachstellen, aber sie sind auch schon länger auf dem Markt und weiter verbreitet.

In einer konkreten Hinsicht ist das Mosh-Protokoll sicherer als das von SSH: SSH verlässt sich auf unauthentifiziertes TCP, um den Inhalt des sicheren Streams zu übertragen. Das bedeutet, dass ein Angreifer eine SSH-Verbindung mit einem einzigen gefälschten „RST“-Segment beenden kann. Im Gegensatz dazu wendet Mosh seine Sicherheit auf einer anderen Ebene an (Authentifizierung jedes Datagramms), so dass ein Angreifer eine Mosh-Sitzung nicht beenden kann, es sei denn, der Angreifer kann kontinuierlich verhindern, dass Pakete die andere Seite erreichen. Ein vorübergehender Angreifer kann nur einen vorübergehenden, für den Benutzer sichtbaren Ausfall verursachen; sobald der Angreifer verschwindet, nimmt Mosh die Sitzung wieder auf.

Im typischen Einsatz verlässt sich Mosh jedoch auf SSH, um zu Beginn einer Sitzung Schlüssel auszutauschen, so dass Mosh die Schwächen von SSH erbt – zumindest insoweit, als sie sich auf die kurze SSH-Sitzung auswirken, die zum Aufbau einer lang laufenden Mosh-Sitzung verwendet wird.

F: Ist Mosh von den 2018 erfolgten Angriffen auf den OCB2-Cipher-Modus betroffen?

Nicht dass wir wüssten – Mosh verwendet OCB3. Die Autoren des Papers schreiben, dass der Angriff nicht auf OCB3 anwendbar ist.

F: Warum verwendet Mosh AES-128 für einen Sitzungsschlüssel und nicht AES-192 oder AES-256?

• AES-128 ist eine mehr als ausreichende Schlüssellänge für einen Sitzungsschlüssel.
• Die OCB-FAQ empfiehlt AES-128.
• AES-128 ist ein bisschen schöner und unterliegt nicht den Angriffen auf verwandte Schlüssel, die AES-192 und AES-256 befallen. (Schneier: „Der Schlüsselplan für die 256-Bit-Version ist ziemlich lausig – etwas, worauf wir in unserem Papier aus dem Jahr 2000 hingewiesen haben – aber das gilt nicht für AES mit einem 128-Bit-Schlüssel.“ Siehe diesen Blogbeitrag.)

F: Funktioniert mosh mit Amazon EC2?

Ja, es funktioniert hervorragend, aber bitte denken Sie daran, die UDP-Ports 60000-61000 auf der EC2-Firewall zu öffnen.

F: Wie kann ich feststellen, ob mosh richtig funktioniert?

Nachdem Sie mosh user@server ausgeführt haben, werden Sie bei Erfolg in Ihre Anmeldeshell auf dem entfernten Rechner geleitet. Wenn Sie überprüfen wollen, ob mosh anstelle von ssh verwendet wird, versuchen Sie Ctrl-^ Ctrl-Z einzugeben, um die Sitzung zu unterbrechen (mit mosh 1.2.4 oder höher auf dem Client). Die Eingabe von fg wird dann zurückkehren.

F: Was ist der Unterschied zwischen mosh, mosh-client und mosh-server? Welchen verwende ich?

Der mosh-Befehl ist ein Wrapper-Skript, das für die primäre Verwendung von mosh gedacht ist. In den meisten Fällen können Sie einfach „ssh“ durch „mosh“ in Ihrer Befehlszeile ersetzen. Hinter den Kulissen verbindet sich das mosh Wrapper-Skript per SSH mit dem Server, startet mosh-server und schließt dann die SSH-Verbindung. Dann startet es die ausführbare Datei mosh-client auf dem Client und übergibt ihr die notwendigen Informationen, damit sie sich mit der neu erzeugten Instanz mosh-server verbinden kann.

Im normalen Gebrauch müssen mosh-client und mosh-server nicht direkt ausgeführt werden.

F: Wie kann ich den Mosh-Client und den Server separat laufen lassen?

Wenn das Wrapper-Skript mosh bei Ihnen nicht funktioniert, können Sie versuchen, die Programme mosh-client und mosh-server separat auszuführen, um eine Verbindung herzustellen. Dies kann eine nützliche Technik zur Fehlersuche sein.

1. Melden Sie sich auf dem entfernten Host an und führen Sie mosh-server aus.

Sie erhalten eine Ausgabe wie:

$ mosh-server MOSH CONNECT 60004 4NeCCgvZFe2RnPgrcU1PQwmosh-server (mosh 1.1.3)Copyright 2012 Keith Winstein <[email protected]>License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.This is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law.

2. Auf dem lokalen Host führen Sie aus:

$ MOSH_KEY=key mosh-client remote-IP remote-PORT

wobei „key“ die 22-Byte-Zeichenfolge ist, die von mosh-server ausgegeben wird (in diesem Beispiel „4NeCCgvZFe2RnPgrcU1PQw“), „remote-PORT“ ist die vom Server angegebene Portnummer (in diesem Fall 60004) und „remote-IP“ ist die IP-Adresse des Servers. Sie können die IP-Adresse des Servers mit „host remotehost“ abfragen.

3. Wenn alles gut geht, sollten Sie eine funktionierende Mosh-Verbindung haben. Informationen darüber, wo der Prozess fehlschlägt, können uns bei der Fehlersuche helfen, warum Mosh bei Ihnen nicht funktioniert.

F: Mit dem mosh-server auf FreeBSD oder OS X bekomme ich manchmal seltsame Farbprobleme. Was ist da los?

Dieser Fehler ist in Mosh 1.2 behoben. Danke an Ed Schouten und Peter Jeremy für das Aufspüren dieses Fehlers.

F: Wie kann ich zu mosh beitragen?

Wir begrüßen Ihren Beitrag! Bitte treten Sie uns im #mosh-Kanal auf Freenode IRC bei, besuchen Sie uns auf GitHub oder schreiben Sie eine E-Mail an [email protected]. Um zu unserer Codebasis beizutragen, forken Sie bitte das Repository auf GitHub und öffnen Sie dort einen Pull Request.

F: Wer hat bei mosh geholfen?

Wir sind sehr dankbar für die Hilfe und Unterstützung von:

• Hari Balakrishnan, der uns bei dieser Arbeit beraten hat und auf den Namen gekommen ist.
• Paul Williams, dessen zurückentwickeltes vt500-Zustandsdiagramm die Grundlage für den Mosh-Parser ist.
• Die anonymen Benutzer, die Sitzungsprotokolle zur Abstimmung und Messung des prädiktiven Echos von Mosh beigesteuert haben.
• Nickolai Zeldovich für hilfreiche Kommentare zum Mosh-Forschungspapier.
• Richard Stallman für hilfreiche Diskussionen über die Möglichkeiten des SUPDUP Local Editing Protocol.
• Nelson Elhage
• Christine Spang
• Stefie Tellex
• Joseph Sokol-Margolis
• Waseem Daher
• Bill McCloskey
• Austin Roach
• Greg Hudson
• Karl Ramm
• Alexander Chernyakhovsky
• Peter Iannucci
• Evan Broder
• Neha Narula
• Katrina LaCurts
• Ramesh Chandra
• Peter Jeremy
• Ed Schouten
• Ryan Steinmetz
• Jay Freeman
• Dave Täht
• Larry Doolittle
• Daniel Drown
• Timo Juhani Lindfors
• Timo Sirainen
• Ira Cooper
• Felix Gröbert
• Luke Mewburn
• Anton Lundin
• Philipp Haselwarter
• Timo J. Rinne
• Barosl Lee
• Andrew Chin
• Louis Kruger
• Jérémie Courrèges-Anglas
• Pasi Sjöholm
• Richard Woodbury
• Igor Bukanov
• Geoffrey Thomas
• Steve Dignam
• HIGUCHI Yuta
• Baruch Siach