Ich teste MoSH bereits seit geraumer Zeit. Zwar sehe ich noch immer einige Probleme dabei, aber es gibt eine Handvoll cooler Features, die SSH weit überlegen sind, weshalb sich ein genauerer Blick darauf durchaus lohnt.
Aber was ist MoSH eigentlich? MoSH biedert sich an, ein drop-in replacement für SSH zu sein. Das ist technisch zwar nicht ganz korrekt, beschreibt aber, was das Programm macht. Eigentlich ist MoSH nur ein Aufsatz auf SSH, so verbindet sich der Client zuerst traditionell über ssh mit dem angegebenen Benutzeraccount und startet dann darüber das MoSH-binary auf einem beliebigen UDP Highport, welches dann die weitere Kommunikation und Authentifizierung übernimmt. Erreich wird dies durch Verwendung von AES-128 OCB erreicht. Das hat den Vorteil, dass alle Authentifikationsmethoden, die z. B. via PAM bereits funktionierten, weiterverwendet werden können. Ferner ist es dadurch auch möglich, MoSH und SSH parallel zu verwenden.
Benutzung
Benutzt wird mosh genauso wie SSH.
$ mosh root@galatea.vpn
Vorteile
Während traditionelle Remote-Shells einen bytestream vom Server zum Client schicken, arbeitet mosh mit Snapshots des Terminalinhalts auf beiden Seiten zwischen denen dann Differenzialabbilder ausgetauscht werden. Erfolgt eine lange Ausgabe wie ein dmesg, wird nicht der ganze Log übertragen und verstopft die Sendewarteschlange, sondern lediglich das, was der Client auch anzeigen kann. Dadurch ist es auch möglich, jederzeit mit Strg-C die Ausgabe zu unterbrechen. Versucht man das mit SSH, wird erst noch der Rest des Puffers übertragen und angezeigt, bis das Unterbrechungssignal ankommt und umgesetzt wird. Das ist besonders dann nervig, wenn die genutzte Verbindung langsam ist oder hohe Paketverluste aufweist.
Stichwort Paketverluste, MoSH biete ein „predictive“ local echo, wodurch es deutlich angenehmer wird, bei einer schlechten Internetverbindung auf dem Server Kommandos zu tippen. Sogar Telnet hatte bereits ein local echo, warum man bei SSH darauf verzichtete, ist mir unbegreiflich. Noch nicht mit dem Server synchronisierte Zeichen werden durch Unterstreichung gekennzeichnet, ebenso erfolgt eine Einblendung, wenn längere Zeit gar kein Kontakt mehr mit dem Server aufgenommen werden konnte.
Einer der Hauptvorteile jedoch ist, dass eine Verbindung unterbrochen und wieder aufgenommen werden kann, z. B. wenn man auf dem Client das Netz wechselt. z. B. von einem WLAN in ein anderes, von WLAN zu Mobilfunk etc. oder aber wenn man den Clientcomputer in den Standby-Modus schickt und später wieder aufweckt.
Als weitere Goodies, beschützt MoSH das umschließende Terminal vor zerstörerischen Escape-Sequenzen und fehlterhaften POSIX UTF-8 Implementierungen. Das setzt allerdings voraus, dass das System auch UTF-8 verwendet. Ohne gehst nicht.
Nachteile
MoSH verlässt sich voll- und ganz auf auf das eingesetzte AES-128 OCB, sollte hier ein Fehler in der Implementierung liegen oder gar eine Angriffsmöglichkeit auf den Cipher selbst, hat man verloren. Dann könnte jede schwebende Verbindung gekapert werden und der Angreifer wäre mit dem eingeloggten User im System. Allerdings auch nur während eine Verbindung mit MoSH gerade aktiv ist. Ist niemand eingeloggt, läuft MoSH nicht und es gibt keinen Angriffspunkt, denn es gibt keinen ständig am Netz lauschenden Dämonen.
MoSH wickelt seine Kommunikation über beliebige (aber auch clientseitig wählbare) UDP Ports ab – das könnte ein Problem bei durch Firewalls gesicherten Servern darstellen. Jede Verbindung benötigt einen UDP Port. Wer keine größeren UDP-Bereiche in der Firewall aufreißen will, könnte an diesem Punkt bereits raus sein.
Nicht alle Programme arbeiten reibungslos durch MoSH, als konkretes Beispiel ist mir hier der Prozessmonitor htop und der Dateimanager mc aufgefallen, der häufig mit nicht-aktueller (oder gar keiner) Statusleiste unten angezeigt wird. Ab- und an erscheint auch der normale bash-Prompt unvollständig. Hier sollte noch einmal nachgebessert werden.
Installation
MoSH kann man hier herunterladen.
MoSH gibt es bereits für viele Systeme nativ, darunter Mac OS X. Diverse Linux Distributionen wie ubuntu und Fedora haben es bereits in ihren Repositories drin, für debian squeeze ist es in den Backports verfügbar, wheezy und höher hat es wiederrum mit an Bord.
Will man MoSH selbst kompilieren, sind einige Abhängigkeiten nötig:
Name | Typischer Paketname |
---|---|
Protocol Buffers | protobuf-compiler, libprotobuf-dev |
ncurses | libncurses5-dev |
zlib | zlib1g-dev |
utempter (optional) | libutempter-dev |
IO::Pty Perl module | libio-pty-perl |
Unter Debian installiert man sich die Abhängigkeiten komfortabel mit folgendem Kommando:
$ aptitude install libprotobuf-dev libncurses5-dev zlib1g-dev libutempter-dev libio-pty-perl protobuf-compiler pkg-config
Für Windows gibt es keinen Port, allerdings gibt es einen (etwas wilden) Ansatz, unter Zuhilfenahme von Cygwin und Cygputty: http://www.zacpod.com/?p=221
Schöne Übersicht. Einige der Details hatte ich selbst aus der Homepage von MoSH nochk nicht herausgelesen. Danke daher.
Inzwischen gibt es übrigens ein (von mir noch nicht getestetes) MoSH Plugin für MobaXterm unter http://mobaxterm.mobatek.net/plugins.html zum herunterladen.
Marcus,
wenn ich Dich richtig verstehe hast Du MoSH im Mobaxterm laufen. Wie hast Du das hinbekommen?
Nee, das hast Du nicht richtig verstanden. Ein MoSH Plugin für mobaxterm ist mir nicht bekannt. Allerdings basiert mobaxterm in Teilen auf CygWin, sodass eine Portierung möglich sein sollte. Das Einzige, was ich zu MoSH unter Windows gefunden hab, war ziemlich wild und in Handarbeit zusammengefrickelt: http://www.zacpod.com/?p=221
Marcus – danke fuer Dein schnelles feedback. Ich habe MoSH (Client) unter CygWin compiliert (mit Hilfe https://gist.github.com/2349067 und https://github.com/keithw/mosh/issues/164) und kann somit remote MoSH server (auch mit non-standard port) erreichen!
All the best, higgins
Wunderbar, das ist doch eine richtige Bereicherung des Artikel. Vielen Dank.