Genau hier setzt SSHPilot an und erweitert das klassische Terminal um eine übersichtliche Oberfläche auf Basis der Libadwaita, die bewusst einfach bleibt und viele SSH-typische Aufgaben deutlich vereinfacht. Damit eignet sich SSHPilot besonders für GNOME-User etwa als Alternative zum Windows-Klassiker PuTTY, den es auch als KiTTY für Linux gibt.

Mehr als nur ein Terminal

SSHPilot präsentiert sich als vollwertiger SSH-Manager mit eingebautem Terminal, der aber jederzeit die Möglichkeit bietet, Verbindungen auch im bevorzugten Terminal zu öffnen. Die Anwendung integriert sich nahtlos in den GNOME-Desktop und unterstützt sowohl helle als auch dunkle Farbschemata. Für das Terminal selbst stehen mehrere Farbpaletten zur Auswahl, die sich unabhängig von den GNOME-Einstellungen auswählen lassen.

Besonders praktisch für erfahrene Anwender: SSHPilot kann bestehende Einstellungen aus der ~/.ssh/config direkt einlesen und dauerhaft speichern. Passwörter und Schlüssel-Passphrasen werden dabei sicher verwahrt, ohne dass sensible Daten im Klartext gespeichert oder unnötig in die Zwischenablage gelegt werden.

Übersichtlichkeit und praktische Verwaltung

Die Bedienung ist darauf ausgelegt, viele Verbindungen und Servergruppen übersichtlich zu verwalten. Ihr könnt Hosts bündeln und per Tastenkombination schnell wechseln, ohne mehrere Terminals parallel offen halten zu müssen. Zusätzlich bindet SSHPilot entfernte Verzeichnisse per SFTP direkt in den Dateimanager der GNOME Desktop-Umgebung ein. So habt ihr bequemen Zugriff auf die Dateien des Servers und könnt Daten ohne Umwege hoch- und herunterladen.

Darüber hinaus unterstützt SSHPilot lokale, entfernte und dynamische Port-Forwardings, womit viele typische SSH-Szenarien abgedeckt werden. Auch SCP für schnellen Datei-Upload ist integriert. Besonders nützlich: Beim Aufbau einer Verbindung können definierte Kommandos automatisch lokal oder auf dem Zielsystem ausgeführt werden, was Routineaufgaben erheblich vereinfacht.

Installation: DEB, RPM oder AUR

Die Installation ist unkompliziert: Für Debian- und Fedora-basierte Systeme gibt es fertige Pakete, und auch ein AUR-Paket für Arch Linux steht bereit. Der Quellcode liegt offen auf GitHub, was Anwendern volle Transparenz und Kontrolle über die eigene Software garantiert. Bei mir hat die Installation über das AUR unter Arch Linux problemlos funktioniert.

$ yay -Ss sshpilot
aur/sshpilot 3.5.4-1 (+0 0.00)
    SSH connection manager with integrated terminal,
    tunneling, tabbed interface and scp upload support.
$ yay -S sshpilot

Nützliche Ergänzung zum klassischen SSH

Für mich ist SSHPilot keine Konkurrenz zum Terminal, sondern eine sinnvolle Ergänzung, die Ordnung schafft und Routineaufgaben erleichtert. Wer regelmäßig zwischen vielen Servern wechselt, Port-Weiterleitungen nutzt oder Dateien überträgt, findet hier einen verlässlichen Helfer. Das Programm bleibt leichtgewichtig und verzichtet auf unnötigen Ballast, wodurch es sich bestens in den Arbeitsalltag integriert. Die DEB- und RPM-Pakete findet ihr auf der Projektseite, sodass die Installation problemlos gelingt.

$ sudo arp-scan --localnet | grep Raspberry
192.168.0.100  b8:27:eb:76:1e:16  Raspberry Pi Foundation
192.168.0.101  b8:27:eb:e4:e1:30  Raspberry Pi Foundation

Bislang war auf den Raspian-Images der SSH-Server von Haus aus aktiv. Somit ließ sich der Raspberry Pi „headless“ aufsetzen. Man brauchte also weder Maus, Tastatur oder einen Monitor um das System des RasPis einzurichten, was die Installation eines RasPi-Servers ungemein vereinfacht. In Anbetracht der IT-Sicherheits-GAUs der letzten Tage und Wochen, macht die Raspberry Pi Foundation mit dieser Praxis nun Schluss: Seit Raspbian 2016-11-25 muss man den SSH-Server aktivieren. Kann man den RasPi direkt bedienen, ist das schnell geschehen, einen Headless-RasPi muss man jedoch gezielt vorbereiten.

SSH auf dem Raspberry Pi aktivieren

Wer auf seinen Raspberry Pi direkt zugreifen kann, weil neben Tastatur/Maus auch noch ein Monitor an dem Minirechner angeschlossen sind, muss zum Aktivieren von SSH keine großen Klimmzüge machen. In der Anwendung Preferences | Raspberry Pi Configuration findet sich im Reiter Interfaces ein Schalter zum Aktivieren des SSH-Servers. Diesen ist weiter von Haus aus installiert, man muss hier nun lediglich den Schalter auf Enabled stellen und den Dialog mit OK beenden.

Alternativ ruft man das konsolenbasierte Raspberry-Pi-Konfigurationswerkzeug mittels sudo raspi-config in einem Terminal auf und schaltet dort unter dem Eintrag 7 Advanced Options | A4 SSH die entsprechende Option ein. Dies funktioniert dann selbstverständlich auch mit dem Light-Image von Raspbian, das auf eine grafische Desktopumgebung verzichtet. Einen Neustart danach braucht es nicht zwingend, man kann man sich sofort wieder per SSH einloggen.

Dabei findet man gleich eine weitere Neuerung. Solange man das Passwort des Standardnutzers „pi“ nicht abändert, es also bei „raspberry“ belässt, bekommt man bei jedem Einloggen einen Hinweis auf den Schirm, dass man dieses doch bitte schnellstmöglichst tun solle. Dazu genügt es sich ganz normal einzuloggen und dann mit dem Kommando passwd das Kennwort abzuändern. Linux-typisch zeigt das System bei dieser Aktion keinerlei Sternchen oder andere Platzhalter an. Alternativ funktioniert das Ändern des Passworts auch über RasPi-Config.

SSH auf einem Headless-RasPi

Möchte man nun aber gar nicht erst einen Monitor und Eingabegeräte an den Raspberry Pi anschließen, dann steht man mit dem neusten Raspbian vor verschlossenen Türen: Konnte man sich früher per SSH direkt auf dem RasPi einloggen, heißt es jetzt nur noch ssh: connect to host 192.168.111.100 port 22: Connection refused und nichts geht mehr. Nun beißt sich die Katze natürlich in den Schwanz: Ohne SSH kein SSH. Doch auch für diesen Fall haben die Entwickler von Raspbian eine Lösung erdacht.

Damit Raspbian von Haus aus SSH aktiviert, schreibt man die Image-Datei wie gewohnt auf die SD-Karte. Nach Abschluss der Aktion nehmt ihr die Karte nun nicht sofort aus dem Kartenleser, sondern öffnet die /boot-Partition des Raspbian-Systems in einem Dateimanager eurer Wahl und erstellt dort eine leere Datei mit dem Namen ssh. Da mit dem FAT-Dateisystem formatiert wurde, funktioniert dies mit allen gängigen Betriebssystem, also mit Linux, MacOS X und auch mit dem Windows Explorer unter Microsoft Windows.

Ich persönlich mache es mir unter Linux ein wenig leichter: Anstatt einen Dateimanager zu bemühen, schreibe ich das Rapbian-Image wie gewohnt mit dd auf die Speicherkarte (Achtung: Bitte Namen und bei Bedarf Pfad der Image-Datei anpassen, sowie den Pfad /dev/sdd zur Speicherkarte ändern) und lege die Datei dann mit touch an. Wobei man auch hier wieder den Pfad zum Mountpunkt der /boot-Partition anpassen muss. Arch bindet externe Medien unter /run/media/benutzername ein. Das $(whoami) sorgt dafür, dass dieser automatisch aufgelöst wird.

$ sudo dd if=2016-11-25-raspbian-jessie.img of=/dev/sdd bs=512; sync
$ touch /run/media/$(whoami)/boot/ssh

In Zukunft wird es also ein klein wenig komplizierter einen Raspberry Pi ohne Monitor und Tastatur entsprechend aufzusetzen. Das Plus an Sicherheit ist es in meinen Augen jedoch wert, ich möchte nicht von einem „Raspberry-Pi-Botnet“ aus der Presse erfahren. Zahlreiche RasPi-User wussten wahrscheinlich gar nicht, dass das System aus dem Netz heraus über SSH zu erreichen war. Wurde dann nicht einmal das Standard-Passwort geändert, war das RasPi-System offen wie ein Scheunentor.

Beim Verbindungsaufbau via SSH speichert der SSH-Client in der Regel den öffentlichen SSH-Schlüssel des entfernten Systems zusammen mit dem Rechnernamen und der IP-Adresse in der Datei ~/.ssh/known_hosts im Homeverzeichnis des aktuellen Benutzers auf dem Client-Rechner. Dies wird unter anderem gemacht, um Man-in-the-Middle-Angriffe zu verhindern, bei denen ein Angreifer vorgibt, der Zielrechner zu sein, sodass man die Zugangsdaten abfischen kann. Nun schlägt diese Sicherheitsmaßnahme aber auch zu, wenn gar keine Bedrohung vorliegt: Etwa wenn man einen RasPi neu aufsetzt und man sich wieder per SSH einzuloggen versucht. SSH meldet dann in so einem Fall in großen Lettern WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED.

SSH nach erneuter Installation des Systems

$ grep 192.168.111.100 ~/.ssh/known_hosts
raspberrypi,192.168.111.100 ecdsa-sha2-nistp256 AAAAE2...ABBBBqf

$ ssh pi@192.168.111.100
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:6rR+0/i3KnPLds3EuGkfWiudIgu8VMpe1xq+X3I3yNM.
Please contact your system administrator.
Add correct host key in /home/toff/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/toff/.ssh/known_hosts:10
ECDSA host key for 192.168.111.100 has changed and you have requested strict checking.
Host key verification failed.

Nun könnte man die Datei ~/.ssh/known_hosts in einen Texteditor öffnen und die problematische Zeile 10 von Hand aus der Liste löschen, es gibt jedoch einen besseren Weg: Mit ssh-keygen -R IP-Adresse lässt sich der Schlüssel aus der Datei mit einem Kommando entfernen, sodass man beim nächsten Aufbau der Verbindung wieder bei „Null“ anfängt — den Schlüssel also wie beim allerersten Verbindungsaufbau zu diesem Rechner bestätigen muss. Das Ganze funktioniert auch, wenn ihr statt der IP-Adresse den Rechnernamen für den Verbindungsaufbau nutzt. Zur Sicherheit kopiert das Kommando den alten Stand nach ~/.ssh/known_hosts.old im selben Verzeichnis.

$ ssh-keygen -R 192.168.111.100
# Host 192.168.111.100 found: line 10
/home/toff/.ssh/known_hosts updated.
Original contents retained as /home/toff/.ssh/known_hosts.old

$ ssh pi@192.168.111.100
The authenticity of host 'raspberrypi (192.168.111.100)' can't be established.
ECDSA key fingerprint is SHA256:6rR+0/i3KnPLds3EuGkfWiudIgu8VMpe1xq+X3I3yNM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.111.100' (ECDSA) to the list of known hosts.
pi@192.168.111.100's password: 

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Apr 22 08:40:10 2016 from 192.168.178.57

SSH-Verbindung gewaltsam trennen

Ist man auf einem entfernten Rechner per SSH eingeloggt und fährt diesen per shutdown, halt oder reboot herunter, dann beendet das System die SSH-Verbindung nicht gewaltsam. Das System beendet den SSH-Server während des Herunterfahrens sauber, sodass man wieder im Terminal des Clients-Rechners landet und dort mit demselben Terminalfenster weiterarbeiten kann. Nun stecke ich — und mit Sicherheit auch andere RasPi-Bastler — ganz gerne den Raspberry Pi vom Strom ab und wieder an, um den Rechner kurz und schmerzlos neu zu starten. Dieses Verfahren ist mit Sicherheit nicht ideal für die Integrität der Daten auf der Speicherkarte, aber wenn ich das System auf dieser sowieso neu aufsetzen möchte, kümmert mich diese wenig.

Der Nachteil ist nun aber, dass bei diesem Vorgang in der Regel auch SSH im Terminal hängen bleibt — schließlich hat man sich gerade den Stuhl unter dem Hintern weggezogen. Nun könnte man den SSH-Prozess abschließen oder das Terminal-Fenster schließen und wieder neu öffnen, doch auch für diese Situation gibt es eine saubere Lösung: SSH kennt eine Reihe von Steuerkommandos, mit denen sich die aktuelle SSH-Sitzung managen lässt. Ihr bekommt eine Übersicht über die zur Verfügung stehenden Kommandos, wenn ihr ~? (also [AltGr]+[+] und [Umschalt]+[ß]) in eine neue Zeile des Terminals eingebt — Man ein Linux-Einsteiger mag [AltGr] verwirren: Mit dieser ist die rechte Alt-Taste neben der Leertaste gemeint. Zur Sicherheit drückt ihr vorher daher einfach einmal auf die Eingabetaste.

pi@raspberrypi:~ # ~?
Supported escape sequences:
 ~.   - terminate connection (and any multiplexed sessions)
 ~B   - send a BREAK to the remote system
 ~C   - open a command line
 ~R   - request rekey
 ~V/v - decrease/increase verbosity (LogLevel)
 ~^Z  - suspend ssh
 ~#   - list forwarded connections
 ~&   - background ssh (when waiting for connections to terminate)
 ~?   - this message
 ~~   - send the escape character by typing it twice
(Note that escapes are only recognized immediately after newline.)

Die von der Hilfe anzeigte erste Sequenz ist bereits die gesuchte Funktion: Gebt ihr während einer SSH-Sitzung als Text ~. ein, drückt also die Tasten [AltGr]+[+] und danach [.], dann beendet ihr die aktuelle SSH-Verbindung ohne Rücksicht auf Verluste. Dies funktioniert eben nicht nur bei einer noch aktiven und weiterhin funktionierenden SSH-Sitzung (die hier ja auch mit exit jederzeit schließen könntet), sondern auch dann, wenn ihr beispielsweise den RasPi vom Strom nehmt und sich im Terminal nichts mehr tut. Auch hier kann es hilfreich sein, vor dem eigentlich Kommando noch einmal zur Sicherheit die Eingabetaste zu drücken. Sonst läuft das Steuerkommando eventuell ins Leere.

SSH-Verbindung pausieren und fortsetzen

Mit den Steuercodes lassen sich jedoch auch andere praktische Dinge machen. So könnt ihr beispielsweise eine SSH-Verbindung unterbrechen und später wieder fortsetzen, ohne dass ihr einen Terminalmultiplexer wie screen oder tmux einsetzen müsst. Braucht ein Prozess mehr Zeit als gedacht, könnt ihr die Verbindung auf diesem Weg parken, der Prozess auf dem entfernten Rechner läuft weiter. Im Gegensatz zu den beiden genannten Terminalmultiplexern müsst ihr nicht im Vorfeld daran denken, dass der Vorgang länger brauchen könnte und diese vorsorglich starten. Das entsprechende Steuerzeichen nennt sich nun etwas kryptisch ~^Z, der Zirkumflex steht dabei nicht als Zeichen, sondern als Steuerzeichen. Ihr müsst also [AltGr]+[+] und danach [Strg]+[Umschalt]+[Z] drücken. Anschließend landet ihr wieder im Terminal des Rechners, auf dem ihr ursprünglich ssh ausgeführt habt. Von dort aus könnt ihr die Verbindung wieder mit dem Aufruf von fg und [Eingabe] aufgreifen.

Arbeitet ihr auf einem „richtig“ entfernten System über das Internet, kann es durchaus passieren, dass die Verbindung abbricht. Dies liegt auf der einen Seite daran, dass der Server bei Inaktivität die Verbindung beendet, auf der anderen Seite kann es zu Situationen kommen, in denen die eigene Netzwerk-Infrastruktur (sprich der Router) dazwischenfunkt: Es gibt jedoch die Möglichkeit den Timeout mit einer Keep-Alive-Funktion zu verhindern. Je nach Situation könnt ihr entweder den SSH-Server entsprechend konfigurieren (dazu benötigt ihr natürlich Root-Rechte) oder ihr ruft die SSH-Verbindung gleich mit den entsprechenden Parameter auf. Für diesen Fall benötigt ihr keine besonderen Rechte auf beiden Systemen.

Keep-Alive serverseitig

### Keep-Alive-Standardeinstellung:
$ grep Alive /etc/ssh/sshd_config
#TCPKeepAlive yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
### Die Konfiguration des SSH-Servers bearbeiten:
$ sudo nano /etc/ssh/sshd_config

### Die entsprechenden Zeilen sollte am Ende so aussehen:
$ grep Alive /etc/ssh/sshd_config
TCPKeepAlive yes
ClientAliveInterval 60
ClientAliveCountMax 3

### SSH-Server einmal neu durchstarten:
$ sudo systemctl restart sshd

Keep-Alive clientseitig

### SSH-Verbindung clientseitig am Leben halten
$ ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=1 pi@raspberrypi

Im ersten Fall gilt die Einstellung für alle User, die sich per SSH auf dem System einloggen möchten. In der Regel sollte man diese Konfiguration daher nur dann vornehmen, wenn auch alle User tatsächlich diese benötigen. Meistens braucht man das Keep-Alive allerdings nur im Ausnahmefall, von daher ist es sinnvoll die Option nur bei Bedarf mit dem Aufruf von ssh zu setzen. Bei mir ist das beispielsweise bei einem Web-Service der Fall, bei dem ich mich per SSH einloggen kann. Stoße ich dann dort längere Zeit laufende Backups an, dann beendet mein Router die Verbindung bevor der Backupprozess erfolgreich den Vollzug melden kann. Mit den genannten Keep-Alive-Settings beim Aufruf ist das jedoch kein Problem mehr.

$ ssh sshtron.zachlatta.com

Gesteuert wird das Spiel über die klassischen Ego-Shooter-Keys W, A, S und D. Mit Escape oder Strg+C beendet ihr das Spiel und damit auch die Verbindung. Das gilt auch für die Pfeiltasten, die man eigentlich zur Steuerung eines solchen Spiels nutzen würde. Ansonsten muss man zum Spielprinzip natürlich nicht mehr viel sagen. Eine KI gibt es nicht – ihr müsst andere Mitspieler einladen. Wer mag, kann SSH Tron auch auf einem eigenen Server im LAN aufsetzen – oder diesen der Allgemeinheit zur Verfügung stellen.

Bereits vor einigen Jahren habe ich mich schon einmal mit dem Thema SSH/SFTP-Server unter Windows mounten beschäftigt. Damals konnte mit Swish nur ein Tool, das im Großen und Ganzen gut funktionierte. Swish klinkt sich direkt in den Windows-Explorer ein und integriert zusätzliche Menüs, über die sich dann SSH/SFTP-Server konfigurieren und in den Explorer einbinden lassen. Aus dem Explorer lassen sich dann Dateien in einem Editor öffnen und bearbeiten und klassisch per Drag&Drop Dateien und Verzeichnisse hin- und herschieben.

Wie ein Kommentator allerdings erst kürzlich schrieb, hat das Programm allerdings einen Haken — Inhalte des gemounteten SSH-Servers kopiert Swish in den temporären Speicher des Rechners und öffnet sie dann lokal von der Festplatte. Ändert man dann diese Dateien, schreibt Swish sie automatisch wieder auf den SSH-Server. Das funktioniert mit Konfigurationsdateien und PHP-/HTML-Dateien ohne große Komplikationen, möchte man aber etwas Musik oder Videos mittels Swish und SSH streamen, dann muss man immer erst einmal abwarten, bis Swish die Daten kopiert hat.

Als brauchbare Alternative zu Swish bietet sich inzwischen nun aber auch Win-sshfs an. Das kostenlose Programm bietet ähnliche Möglichkeiten wie Swish, muss aber die entfernt gelagerten Daten nicht erstmal vollständig kopieren, bis andere Anwendungen auf diese zugreifen können — Wie von Linux gewohnt, sind gemountete Daten einfach da. Aktuell wird das Programm nicht aktiv weiterentwickelt, allerdings konnte ich in meinem kurzen Test unter Windows 7 keine Probleme feststellen. Es müsste sich daher auch bei euch noch gut machen.

Die Installation von Win-sshfs gelingt über eine Installationsroutine, die etwaige fehlende Komponenten aus dem Netz lädt. Zum Abschluss der Installation ist ein Neustart des Systems notwendig. Nach diesem sollte Win-sshfs eigentlich automatisch mitstarten. Falls nicht, ruft ihr das Programm aus dem Startmenü aus, es nistet sich dann als Icon in das Statusmenü von Windows ein. Mit Show Manager ruft ihr dort dann den Sshfs Manager auf, in dem ihr die von euch genutzten SSH-Zugänge einrichten könnt.

Mit Save speichert ihr eure Änderungen ab, mit Mount bindet ihr dann den SSH-Server als Netzwerklaufwerk ein. Soll der Server direkt nach dem Start verfügbar sein, dann achtet drauf, dass Win-sshfs mit Run at startup automatisch mit dem Rechner gestartet wird und die Option Mount at login dafür sorgt, dass Win-sshfs die Daten des SSH-Servers automatisch einbindet. Ein oft genutzter SSH-Server ist somit auch unter Windows immer in Reichweite.

Mosh wurde als SSH-Ersatz für instabile (die Verbindung darf komplett abbrechen, man kann sogar den Rechner in den Standby schicken) , wechselnde (man kann eine Mosh-Verbindung mit UMTS starten und über ein WLAN wieder aufnehmen) und langsame Internetverbindungen (Tastatureingaben werden bevorzugt durchgeleitet) geschaffen. Also etwa für die User, die sich mit einer wackligen UMTS-Leitung per SSH auf einen Server verbinden möchten. Es gibt Mosh für Linuxe, Windows und Macs und natürlich auch für mobile Betriebssysteme. So kann man Mosh vom PC und vom Handy aus benutzen.

Mosh neben SSH auf dem Server installieren

Um Mosh zum Laufen zu bekommen, muss das Programm auf beiden Rechnern installiert werden. Auf dem Server muss natürlich noch zusätzlich SSH installiert sein, da SSH weiterhin zur Authentifizierung des Users und zum Verbindungsaufbau benötigt wird. Mosh krallt sich erst nach dem Aufbau der verschlüsselten Leitung die Kontrolle über die Kommunikation.

# Mosh unter Debian/Ubuntu installieren...
$ sudo apt-get install mosh
# Mosh unter Arch Linux installieren...
$ sudo pacman -S mosh

Unter Ubuntu gibt es Mosh seit Precise ganz regulär in den Paketquellen, daher erspare ich mir Ausführungen über das Mosh-PPA. Dort gibt es allerdings aktuellere Versionen von Mosh, von daher könnte das PPA auch bei aktuelleren Ubuntus interessant sein. Arch-User finden Mosh ganz normal im Community-Repo. Und auch unter zahlreichen anderen Linuxen lässt sich Mosh ganz normal über die Paketquellen installieren, die Mosh-Homepage listet die Installationswege recht umfassend auf.

Mosh ohne Root-Rechte? Geht… vielleicht!

Problematisch wird es allerdings wenn man Mosh mit einem Server nutzen möchte, auf dem man zwar über ein SSH-Login verfügt, aber keine Root-Rechte hat. Mosh lässt sich in der Theorie ohne Root-Rechte — auch auf der Seite des Servers — betreiben, daher kann man sich Mosh auch selber kompilieren und beim Login ausführen. Mit install-user-mosh.sh findet ihr auch ein Skript, mit dem sich Mosh ohne große Aktion bauen lässt.

Allerdings braucht es zum erfolgreichen Bauen von Mosh eine lange Latte von Bibliotheken und Build-Tools, die wahrscheinlich nur auf wenigen Servern installiert sein dürften. Von daher solltet ihr lieber gleich beim Administrator des Servers anklopfen und lieb drum bitten doch schnell Mosh zu installieren. So wird das Programm sauber installiert, Sicherheitslücken geflickt und ihr müsst nicht groß basteln.

# Mosh auch ohne Root-Rechte installieren...
$ wget https://gist.githubusercontent.com/ViViDboarder/11000123/raw/1b71e37006db1d7dfdf8c59e4ba111d73645bec1/install-user-mosh.sh
$ chmod +x install-user-mosh.sh
$ ./install-user-mosh.sh

# Allerdings nur mit diesen Abhängigkeiten...
$ sudo apt-get install g++ protobuf-compiler libprotobuf-dev libboost-dev libutempter-dev libncurses5-dev zlib1g-dev expect-dev libexpect-perl liblocales-us-perl liblocales locales-all liblocale-us-perl liblocales-perl git libssl-dev

Mit Mosh auf den Server verbinden

Wurde Mosh auf Server und Client installiert, kann man wie gewohnt seine SSH-Verbindung aufrufen. Im Normalfall ersetzt ihr einfach das „ssh“ vor dem Befehl mit einem „mosh“, die Angabe des Users und des Servers bleiben gleich. Ein bisschen aufwändiger wird es allerdings, wenn man seinen SSH-Server nicht wie üblich auf Port 22 laufen hat, in diesem Fall muss man den von SSH benutzten Port ein wenig umständlicher angeben.

# Mit Mosh zu einem SSH-Server verbinden...
$ mosh du@dein.server.de
# Mit Mosh zu einem SSH-Server auf Port 222 verbinden...
$ mosh --ssh="ssh -p 222" du@dein.server.de

Ansonsten kann man nun genauso auf dem Server arbeiten, wie man es von SSH gewohnt ist — fast! Um Daten zu sparen überträgt Mosh immer nur die letzten Änderungen in der Shell. Was schon einmal übertragen wurde, wird noch nochmal auf den Server geschickt. Unter anderem deshalb funktioniert der Scrollback-Speicher nicht. Man kann also nicht mit Shift-PageUp/PageDown oder mit dem Mausrad die letzten Ausgaben der Shell hervorholen.

Mosh für Android und Chrome/Chrome OS

Wie schon mehrfach angesprochen ist Mosh natürlich ideal für mobile Geräte. Daher ist es auch nicht verwunderlich, dass es Mosh-Clients für Handys gibt — allerdings wohl nur für Android. Android-User können auf JuiceSSH zurückgreifen, ein SSH-Client für Android den ich schon mehrfach hier im Blog hatte. Die App kostet eine Kleinigkeit, sie ist aber definitiv ihr Geld wert. Mosh lässt sich dort in den Settings der Verbindung einstellen. Und auch für Chrome-, Chromium oder Chrome-OS-User gibt es eine Mosh-Browser-App, die sich direkt im Webbrowser ausführen lässt.

Wie schon zur Feier von 100.000 Installation, gibt es auch beim „nächsten“ Meilenstein von 500.000 Installationen die Pro-Version der App bis zum 18. März 11:00 GMT wieder kostenlos. Wer die Aktion beim letzten mal verpasst hat und sich die 5 Euro für die Pro-Version sparen möchte, kann also jetzt wieder zugreifen. Um das Upgrade zu bekommen, müsst ihr eure im Play Store genutzte E-Mail-Adresse auf der Homepage der Entwickler eintragen. Alle weiteren Infos zum Freischalten des Upgrades bekommt ihr dann nach 2 bis 8 Stunden zugeschickt.

JuiceSSH macht es einem hier leichter: Der SSH-Client für Android blendet über der eigentlichen Android-Tastatur noch Zusatztasten wie Ctrl, Alt, Tab oder Cursor-Tasten ein. So kann man recht bequem über SSH auch unter Android arbeiten. Auch sonst bietet die App eigentlich alles was das SSH-Herz begehrt, die Entwickler der App sind beide Vollzeit-Admins.

JuiceSSH ist im Gegensatz zu ConnectBot keine freie Software. Die Play-Store-Version ist in der Basisvariante kostenlos, über einem 4,99 Euro teuren In-App-Kauf kann man auf die Pro-Version umsteigen. Mit dieser kann man dass Port-Weiterleitungen einrichten, die App-Daten über einen Cloud-Speicher zwischen seinen Androiden abgleichen oder in Gruppen zusammenarbeiten.

Zur Feier der 100.000sten Installation der App haben die Entwickler ein Giveaway gestartet. Jeder User kann kostenlos auf die Pro-Version umsteigen. Tretet dafür einfach via Google+ der JuiceSSH-100k-Giveaway-Community bei und schreibt anschließend eine formlose E-Mail an die Entwickler unter 100k AT sonelli.com mit der E-Mail-Adresse eures Google-Accounts. Nach Abschluss der Aktion werden die Pro-Funktionen entsprechend aktiviert.

Schaut man sich das Changelog von KiTTY an, dann sieht man dass KiTTY nicht als Fire&Forget-Projekt angelegt ist. Der Entwickler baut nach dem Release einer neuen PuTTY-Version auch immer wieder auch sein KiTTY neu, so baut die aktuelle Kitty-Ausgabe auch auf die aktuelle PuTTY-Version auf. Ewig mitgeschleppte Sicherheitslücken sind also nicht zu erwarten. Einziger „Haken“ an KiTTY scheint zu sein, dass man sich auf Windows konzentriert und nur für dieses System Binaries baut. In meinen Augen ist das sehr zu verkraften, da ich PuTTY eigentlich wirklich nur unter Windows nutze.

//PS: Ein konkreter Nutzen fällt mir spontan ein. Nicht jeder darf auf seiner Arbeitskiste Software installieren, hat aber Chrome/Chromium zur Verfügung. Oder man nutzt einen Chrome mit der SSH-Erweiterung als mobile App auf einem USB-Stick. Gibt sicherlich noch ein paar weitere sinnvolle Anwendungsfälle und Chrome OS gibt’s ja schließlich auch noch.