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.

Ursprünglich hatte ich auch gedacht, dass LanguageTool eine ideale Ergänzung für meinen Raspberry Pi wäre, der hier im LAN bereits als File-, Drucker- und Scan-Server sowie generell als stromsparende eierlegende Wollmilchsau arbeitet. Doch hier wirds leider hakelig: LanguageTool benötigt zwingend ein 64 Bit-System als Basis. Das bietet die vierte Generation des Raspberry Pi zusammen mit der ARM64-Version des Raspberry Pi OS zwar, doch am Ende scheitert es an Java-Bibliotheken, die auch auf dieser Version des Betriebssystems nur in der 32 Bit-Version vorliegen. Auf die Situation gehe ich am Ende des Artikels ein. Im Folgenden nutze ich einen kleinen Server auf Basis von Debian.

Installation von LanguageTool

Für den LanguageTool-Server benötigt ihr ein Linux-System mit einer Java-Runtime-Umgebung. Auf einem Debian-basiertem System, wie etwa auch Ubuntu oder Linux Mint, spielen die folgenden Kommandos alles Nötige ein. Die Installation der N-Gramm-Daten (zum Erkennen von Schreibfehler wie „viel“ statt „fiel“, „seit“ statt „seid“ oder „Stil“ statt „Stiel“) ist optional. Sie verbessert die Erkennung von oft falsch geschrieben Wörter, schaufelt allerdings nochmal ein paar Gigabyte mehr an Daten auf den Rechner. Für optimale Ergebnisse würde ich diesen Schritt allerdings nicht übergehen und zumindest die N-Gramm-Daten für Deutsch einspielen.

### Installation von LanguageTool:
$ sudo apt install default-jre-headless unzip
$ sudo apt install hunspell hunspell-de-de hunspell-en-us
$ wget https://languagetool.org/download/LanguageTool-stable.zip
$ unzip LanguageTool-stable.zip
$ sudo mv LanguageTool-*.*/ /opt/LanguageTool
$ rm LanguageTool-stable.zip

### Installation der N-Gramm-Daten für Deutsch (~3,5 GByte):
$ sudo mkdir /opt/LanguageTool/ngrams
$ wget https://languagetool.org/download/ngram-data/ngrams-de-20150819.zip
$ sudo unzip ngrams-de-20150819.zip -d /opt/LanguageTool/ngrams
$ rm ngrams-de-20150819.zip
### Installation der N-Gramm-Daten für Englisch (~8,0 GByte):
$ wget https://languagetool.org/download/ngram-data/ngrams-en-20150817.zip
$ sudo unzip ngrams-en-20150817.zip -d /opt/LanguageTool/ngrams
$ rm ngrams-en-20150817.zip

### LanguageTool benötigt über 3 GByte Speicherplatz:
$ du -hs /opt/LanguageTool
3.4G	/opt/LanguageTool

Für einen ersten Test wechselt ihr nun auf dem Terminal in das Installationsverzeichnis unter /opt/LanguageTool des LanguageTool-Archivs. Das zweite Kommando aus dem folgenden Listing startet dann testweise die Server-Komponente von LanguageTool. Der Dienst lauscht auf Port 8081 auf Anfragen, mehr braucht es bei diesem Schritt auch noch nicht. Mit der Tastenkombination [Strg]+[C] beendet ihr den Dienst und kehrt wieder auf die Shell zurück.

$ cd /opt/LanguageTool
$ java -cp languagetool-server.jar org.languagetool.server.HTTPServer --port 8081
2021-12-17 20:47:34.423 +0100 INFO  org.languagetool.server.DatabaseAccessOpenSource Not setting up database access, dbDriver is not configured
2021-12-17 19:47:34 +0000 WARNING: running in HTTP mode, consider running LanguageTool behind a reverse proxy that takes care of encryption (HTTPS)
2021-12-17 19:47:37 +0000 Setting up thread pool with 10 threads
2021-12-17 19:47:37 +0000 Starting LanguageTool 5.5 (build date: 2021-10-02 12:33:00 +0000, 5e782cc) server on http://localhost:8081...
2021-12-17 19:47:37 +0000 Server started

Damit LanguageTool jetzt die von euch optional installierten N-Gramm-Daten integriert, erstellt ihr nun mit einem Editor wie Nano unterhalb des Ordners /opt/LanguageTool die Konfigurationsdatei languagetool.cfg. Als Inhalt fügt ihr die Ausgabe nach dem im folgenden Listing eingefügten Kommando cat languagetool.cfg ein. Mit der Tastenkombination [Strg]+[O] und [Eingabe] speichert ihr die Änderung des Editors ab, mit [Strg]+[O] geht es dann zurück auf die Shell. Selbstverständlich könnt ihr auch jeden anderen Editor verwenden.

$ sudo nano /opt/LanguageTool/languagetool.cfg
$ cat languagetool.cfg
languageModel=/opt/LanguageTool/ngrams/

LanguageTool-Server automatisch starten

Damit der LanguageTool-Server nun automatisch mit dem Rechner hochfährt, legt ihr eine sogenannte Unit für Systemd an. Dazu übertragt ihr den Inhalt aus dem folgenden Listing in die noch zu erstellende Datei /etc/systemd/system/languagetool.service. Orientiert euch beim Aufruf des Editors an der Nano-Zeile im vorhergehenden Listing. Alle Pfade beziehen sich auf den bei der Installation gewählten Ordner /opt/LanguageTool. Habt ihr ein anderes Installationsziel gewählt, müsst ihr die Pfade selbstverständlich in der Unit-Datei anpassen.

[Unit]
Description=LanguageTool
After=syslog.target
After=network.target

[Service]
Type=simple
User=languagetool
Group=nogroup
WorkingDirectory=/opt/LanguageTool
ExecStart=/usr/bin/java -cp /opt/LanguageTool/languagetool-server.jar org.languagetool.server.HTTPServer --config languagetool.cfg --port 8081 --allow-origin "*" --public
Restart=always
#Environment=USER= HOME=/opt/LanguageTool

[Install]
WantedBy=multi-user.target

Damit LanguageTool nicht mit Root-Rechten oder mit den Rechten eures Benutzers laufen muss, legt ihr nun noch einen eigenen System-Benutzer mit dem Namen languagetool an, ein Home-Verzeichnis braucht er nicht. Er muss sich auch nicht anmelden, daher wird auch kein Passwort gesetzt. Anschließend lasst ihr Systemd seine Konfiguration neu einlesen und aktiviert das Starten des LanguageTool-Servers. Danach ruft ihr den Dienst einmal von Hand auf und lässt euch zur Kontrolle den Status ausgeben. Der Dienst sollte sich mit active (running) zurückmelden und auch die ersten Logeinträge ausgeben.

$ sudo adduser --system --no-create-home languagetool
$ sudo systemctl daemon-reload
$ sudo systemctl enable languagetool
$ sudo systemctl start languagetool
$ sudo systemctl status languagetool
● languagetool.service - LanguageTool
● languagetool.service - LanguageTool
     Loaded: loaded (/etc/systemd/system/languagetool.service; disabled; vendor preset: enabled)
     Active: active (running) since Sat 2021-12-18 00:36:38 CET; 4s ago
   Main PID: 4763 (java)
      Tasks: 14 (limit: 2314)
     Memory: 72.3M
        CPU: 1.569s
     CGroup: /system.slice/languagetool.service
             └─4763 /usr/bin/java -cp /opt/LanguageTool/languagetool-server.jar org.languagetool.server.HTTPServer --config languagetool.cfg --port 8081 --allow-origin * --public

Dez 18 00:36:38 lui-test systemd[1]: Started LanguageTool.
Dez 18 00:36:39 lui-test java[4763]: 2021-12-18 00:36:39.486 +0100 INFO  org.languagetool.server.DatabaseAccessOpenSource Not setting up database access, dbDriver is not configured
Dez 18 00:36:39 lui-test java[4763]: 2021-12-17 23:36:39 +0000 WARNING: running in HTTP mode, consider running LanguageTool behind a reverse proxy that takes care of encryption (HTTPS)
Dez 18 00:36:39 lui-test java[4763]: 2021-12-17 23:36:39 +0000 WARNING: running in public mode, LanguageTool API can be accessed without restrictions!
Dez 18 00:36:40 lui-test java[4763]: 2021-12-17 23:36:40 +0000 Setting up thread pool with 10 threads
Dez 18 00:36:40 lui-test java[4763]: 2021-12-17 23:36:40 +0000 Starting LanguageTool 5.5 (build date: 2021-10-02 12:33:00 +0000, 5e782cc) server on http://localhost:8081...
Dez 18 00:36:40 lui-test java[4763]: 2021-12-17 23:36:40 +0000 Server started

Chrome/Firefox und LibreOffice konfigurieren

Im Gegensatz zur LanguageTool-Erweiterung für LibreOffice arbeiten die Browser-Erweiterungen für Chrome und Firefox in der Standardkonfiguration immer mit dem kommerziellen Backend des Dienstes zusammen. Um nun euren eigenen LanguageTool-Server in die Einstellungen einzutragen, öffnet ihr (unter Chrome) über das Menü mit den drei Punkten rechts oben den Eintrag Weitere Tools | Erweiterungen. Dort sucht ihr dann die Karte zur Grammatik- und Rechtschreibprüfung – LanguageTool heraus und tippt auf den Button Details, im nächsten Dialog dann weiter auf die Optionen. In den Einstellungen zu LanguageTool angekommen, müsst ihr euch via Ausloggen vom Dienst abmelden. Danach könnt ihr unter Experimentelle Einstellungen (nur für Profis) die URL zum eigenen LanguageTool-Server in der Art http://Server-IP:Port/v2 eintragen.

Ähnlich funktioniert die Konfiguration auch mit der LanguageTool-Erweiterung für LibreOffice. Hier öffnet ihr über den Menüeintrag Extras | LanguageTool | Optionen… die Einstellungen. Die URL zu eurem Server tragt ihr dann im Reiter Allgemein ein. Im Gegensatz zur Konfiguration der Browser-Erweiterung kommt hier allerdings kein /v2 an das Ende der URL. Es genügt die Server-IP zusammen mit der Nummer des Ports einzutippen. Das N-Gramm-Verzeichis (wie im Screenshot abgebildet) müsst ihr nicht zwingend lokal abspeichern. Nutzt ihr einen Server mit eigenen N-Gramm-Daten, ist dieser Schritt natürlich nicht nötig.

LanguageTool auf einem Raspberry Pi

Im Prinzip erfüllt der Raspberry Pi die Anforderungen von LanguageTool: Ausreichend Speicherplatz lässt sich mit einer entsprechend großen Speicherkarte schaffen. Auch die Rechenkapazität der vierten Generation des Mini-Rechners genügt vollkommen. Und der Raspberry Pi 4 lässt sich zusammen mit der ARM64-Version des Raspberry Pi OS auch mit 64 Bit fahren, den Server gibt es nur in einer 64-Bit-Version. Die Installation und der Aufruf funktioniert daher auch, schiebt man allerdings die ersten Texte zur Korrektur auf den Raspberry Pi, dann meldet das System Probleme mit Hunspell und BridJ.

pi@raspberrypi:/opt/LanguageTool $ java -cp /opt/LanguageTool/languagetool-server.jar org.languagetool.server.HTTPServer --config languagetool.cfg --port 8081 --allow-origin "*" --public
[...]
/tmp/BridJExtractedLibraries1395486954380915815/libbridj.so: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden (Possible cause: can't load AMD 64-bit .so on a AARCH64-bit platform))
[...]
Caused by: java.lang.RuntimeException: Could not create hunspell instance. Please note that LanguageTool supports only 64-bit platforms (Linux, Windows, Mac) and that it requires a 64-bit JVM (Java).

Die Thematik wird bereits im Github des LanguageTool-Projekts diskutiert. Dort gibt auch einen Patch für BridJ sowie einen Workaround für Hunspell — ich habe beides allerdings hier bei mir nicht zum Laufen gebracht. Wer noch ein wenig mehr Experimentieren möchte, dem würde ich zu diesem Docker-Image für LanguageTool von Erik van Leeuwen raten. Es soll auch auf ARM64 laufen, also auch auf einem Raspberry Pi der vierten Generation. Ich habe hier bei mir allerdings LanguageTool inzwischen zufriedenstellend auf einem kleinen Intel Nuc laufen, von daher habe ich mich nicht weiter mit dem Betrieb von LanguageTool auf einem Raspberry Pi beschäftigt.

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.

Mit Munin for Android lassen sich gleich mehrere Munin-Server abfragen, über die Sidebar kann man schnell zwischen den einzelnen Einträgen switchen. Die Graphen holt sich die App direkt aus Munin,  per Wisch kommt man von einem Graphen zum anderen, alternativ auch per Sidebar. Rechts unten findet sich eine Checkbox, über die sich der Tages-, Wochen-, Monats- oder Jahres-Graph abrufen lässt.

Wer sich nicht scheut per In-App-Kauf 1,49 Euro in das Feature-Pack für Munin for Android zu investieren, der kann sich die Munin-Graphen zudem auch als Widget auf den Homescreen legen, sich bei Problemen wie einer zu vollen Platte oder einer permanent zu hohen Load benachrichtigen lassen und auch die mit der Munin-Instanz ausgetauschten Daten verschlüsselt per SSL abrufen.

Ein klarer Fall für VNC, doch was macht man wenn – wie heutzutage üblich – das NAT eines Hardware-Routers im Weg steht? Jemandem die Einrichtung einer Portweiterleitung auf einem unbekannten DSL-Router über das Telefon zu erklären ist ein Ding der Unmöglichkeit. Die Lösung dazu nennt man „Reverse-VNC“, dabei baut der VNC-Server zu einem VNC-Client, der im „Listen“-Modus gestartet wurde, aktiv eine Verbindung auf. Auf der Serverseite ist somit keine Portweiterleitung mehr nötig, diese ist nun auf der Seite des Clients – sollte man selber hinter einem Router sitzen – Pflicht. So umgeht man das einrichten einer Portweiterleitung beim „Kunden“.

Die c’t hat dem Thema letztes Jahr einen recht ausführlichen Artikel gewidmet, allerdings gibt es ein paar Stolpersteine, die es zum Umgehen gilt. Dazu ein paar Tipps.

Was braucht man?

Portweiterleitung

Sollte man selber hinter einem Router sitzen, so muss man einen Port vom Router auf den eigenen Rechner weiterleiten. Üblicherweise ist dies für VNC der Port 5500.

DynDNS-Adresse

Im Laufe dieses Artikels muss die eigene Internet-IP in einem Programm fest verdrahtet werden. Da die meisten DSL-Anbieter jedoch nach 24h die Einwahlverbindung trennen und beim erneuten Aufbau der Verbindung eine neue IP zugewiesen wird, macht es wenig Sinn eine IP einzutragen.

Dies lässt sich mit so genannten DynDNS-Anbietern umgehen. Diese – meist kostenlosen – Dienstleister verknüpfen die eigene Internet-IP mit einem Domainnamen. Ein kleines Programm auf dem eigenen Rechner (oder dem DSL-Router) aktualisiert die IP nach einem Wechsel beim DynDNS-Provider. Dadurch ist der eigene Rechner immer unter einer festen URL zu erreichen. Weitere Infos finden sich beispielsweise hier im Wiki von ubuntuusers.de.

Der „One-Click“ VNC-Server

Das alles war bislang nur „Vorspiel“. Nun geht es darum einen speziell angepassten VNC-Server zu erstellen bzw. den VNC-Server unseres Kunden mit den passenden Optionen zu starten. Um es dem Kunden so leicht wie möglich zu machen, wird ein VNC-Server erstellt, der einfach nur ausgeführt werden muss. Der Hilfesuchende muss rein gar nichts einstellen.

Windows/MacOS X

uVNC bietet dafür den PCHelpWare VNC-Server an. Allerdings muss man diesen von Hand über Konfigurationsdateien anpassen. Aufgrund der schlechten Dokumentation ein etwas mühseliges Unterfangen.

Praktischer ist ein Webtool der c’t. Hier müssen nur die eigene DynDNS-Adresse und ein paar erklärende Text eingefügt werden und mit einem Click erzeugt man den Server. Die generierte .exe Datei kann man dem Hilfesuchenden zukommen lassen.

Ist die Datei beim Kunden angekommen, so muss die .exe einfach nur über einen Doppelklick ausgeführt werden. Über einen weiteren Doppelklick auf die Verbindung wird die VNC-Verbindung aufgebaut. Allerdings muss dazu erst der eigene VNC-Client in dem „listen“-Modus gestartet werden, dazu gleich mehr. Der Server muss weder installiert, noch konfiguriert noch – nach Gebrauch und hoffentlich erfolgreicher Problemlösung – deinstalliert werden. Einfach die .exe Datei löschen reicht.

Hinweis: So gut wie jeder Virenscanner meldet bei solchen VNC-Server einen Trojaner. Klar, die Technik wird eben auch von den „Bösen“ angewendet. Daher ist es praktisch unmöglich die .exe per Email zu verschicken. Alle großen Email-Anbieter (ich habe web.de, GMX und Google Mail getestet) filtern das Attachment raus. Daher stellt man den VNC-Server am besten über einen Webserver zur Verfügung und verschickt nur die URL zur Datei.

Nun zum ersten Stolperstein. Der PCHelpWare VNC-Server arbeitet nur mit der Version 3.3 des VNC-Protokolls, die VNC-Client Programme von Linux jedoch nur mit der Version 4. Startet man also ein VNC-Viewer im Listen Modus, so sieht man außer

$ xtightvncviewer -listen 9500 -encodings "hextile copyrect"
xtightvncviewer -listen: Listening on port 15000
xtightvncviewer -listen: Command line errors are not reported until a connection comes in.
Connected to RFB server, using protocol version 3.8

nichts. Der Desktop des entfernten Rechners erscheint nicht auf dem eigenen Bildschirm. Die Optionen -encodings „hextile copyrect“ sollen angeblich helfen das Problem zu lösen, doch ich kann keine Besserung feststellen.

Die Lösung besteht aus der Installation einer vorkompilierten Version des RealVNC Viewers. Pakete und Archive für Linux lassen sich von hier nach einer Registrierung herunterladen. Hinter den Einträgen von

• VNC Enterprise Edition for Linux (x86), für 32-bit Linuxe
• VNC Enterprise Edition for Linux (x64), für 64-bit Linuxe

findet man Links zu einem „Debian Package“, das sich bequem in Ubuntu oder Debian installieren lässt. Allerdings beinhaltet das Paket den Server wie auch den Client. Alternativ kann man sich nur den Client als .tar.gz Archiv herunterladen.

• VNC Enterprise Edition Viewer for Linux (x86), für 32-bit Linuxe
• VNC Enterprise Edition Viewer for Linux (x64), für 64-bit Linuxe

Sollte man sich für das .deb Paket aus Client und Server entschieden haben, so kann man nun den Viewer über

$ vncviewer -listen 5500 -Protocol3.3

starten. Die Option -Protocol3.3 sagt dem Client dass das ältere Protokoll genutzt werden soll. Sollte man den reinen Client gewählt haben, so gilt das das Archiv zu entpacken, das Binary ausführbar zu machen und den Client dann zu starten

$ gunzip vnc-E4_4_3-x64_linux_viewer.gz
$ chmod +x vnc-E4_4_3-x64_linux_viewer
$ ./vnc-E4_4_3-x64_linux_viewer -listen 5500 -Protocol3.3

Von nun an können Hilfesuchende (Windows-User) uns mit ihren Fragen quälen. Solange ihr Internetzugang funktioniert bekommen sie den Client per Download von meinem Webserver, ich starte meinen VNC-Client und schon sehe ich ihren Desktop.

Linux

Tja fehlt nur noch Linux als System. Hier muss man nicht lange Frickeln. Linux bringt von Haus aus alles mit. Wichtig ist nur die Installation des x11vnc-Servers. Danach muss der Kunde nur ein Kommando ausführen.

$ sudo apt-get install x11vnc
$ x11vnc -connect dyndns.example.com

und der Helfer mit vncviewer -listen vorher seinen VNC-Client im Listen-Modus gestartet haben. Und schon sieht man seinen Desktop. Die Portweiterleitung und der Einsatz von DynDNS sind natürlich nach wie vor nötig. Viel Spaß mit dem höchstpersönlichen Helpdesk.

Noch ein Disclaimer: Natürlich gibt es kommerzielle Dienste wie TeamViewer und Co. die einen ähnlichen Service anbieten. Mir persönlich sind diese Dienste nicht sympatisch bzw. ich halte sie nicht für nötig. Mit dem „One-Click“ VNC-Server lässt sich das Thema ohne einen kommerziellen Dienst mit den Bordmitteln eines Linux lösen. Und Hilfesuchende mit Linux haben eh alles an Bord.

Selbst der Autor von ntpdate rät vom Einsatz von ntpdate und Cron für diese Aufgabe ab. Warum sollte man nicht ntpdate über Cron nutzen, sondern einen Time-Server wie ntp? ntpdate aktualisiert die Uhrzeit auf einen Schlag. Geht die Systemzeit 10 Minuten vor und man ruft ntpdate auf, so ist es auf dem System sofort 10 Minuten „früher“.

Was ist daran schlimm? Nur um ein triviales Beispiel zu nennen. Ein Linux schreibt viele Logdateien. Wird die Uhrzeit nun auf einen Schlag um 10 Minuten nach hinten gestellt, so gibt es auf einmal Logeinträge die zur selben Uhrzeit erstellt wurden, aber eigentlich 10 Minuten auseinander liegen. Oder es gibt Prozesse, die eine Authentifizierung für eine gewisse Zeit erlauben, ein schlagartiges Ändern der Zeit kann hier problematisch werden, weil diese Authentifizierung auf einmal ablaufen. Daher ist der Einsatz von ntpdate und Cron ganz speziell auf Servern eine wirklich schlechte Idee.

Was macht ntpd nun anders? ntpd korrigiert die Zeit des Systems allmählich. Geht die Systemuhr nach, so wird sie etwas beschleunigt, geht die Zeit vor, so wird sie gebremst. Die geschieht schleichend, so dass im System nichts durcheinander gebracht wird. Des weiteren lernt ntpd wie die Systemuhr falsch geht und korrigiert sie so automatisch. Wie lässt man nun den Rechner über ntpd korrekt seine Zeit stellen? Dazu muss nur das Paket ntpd installiert werden…

$ sudo apt-get install ntp

Anschließend sollte man noch einen Zeitserver in der eigenen Umgebung einstellen. Von Haus aus benutzt Ubuntu bspw. den Zeitserver ntp.ubuntu.com. Um die Latenzzeit zu verbessern, sollte man in der /etc/ntp.conf daher bspw.

server ntps1-0.cs.tu-berlin.de
server ntps1-1.cs.tu-berlin.de

eintragen, um die Zeitserver der TU-Berlin zu benutzen. Damit diese Änderung aktiv wird muss letztendlich noch der Dienst neu gestartet werden.

$ sudo /etc/init.d/ntp restart

Alternativ bietet GNOME die automatische Installation des ntpd-Dienstes an. Man öffnet einfach System | Systemverwaltung | Datum und Uhrzeit aus und wählt die Option Synchronisierung mit Internet-Servern aufrecht erhalten aus. Danach wird automatisch ntp installiert.

Ruf man den Dialog anschließend nochmal auf, so kann man über eine graphische Oberfläche bequem und einfach die zu benutzenden Zeitserver auswählen.

The kernel requires the following features not present on the CPU 0:6
Unable to boot – please use a kernel appropriate for your CPU

…und der Bootvorgang bricht ab. Dies liegt daran dass bei Ubuntu Server ein für Server optimierten Kernel installiert wird. Dieser unterstützt PAE. So kann die CPU selbst dann mehr als 4GB RAM adressieren, wenn kein 64-bit Betriebssystem installiert ist. VirtualBox unterstützt diese Technik, sie ist nur von Haus aus deaktiviert, man muss sie nur aktivieren, dann bootet Ubuntu Server auch.

Dazu öffnet man die Einstellungen der betroffenen virtuellen Maschine und aktiviert die Option PAE/NX aktivieren. Startet man nun die virtuelle Maschine mit Ubuntu Server. So bootet sie und man kann mit dem neuen Serverchen arbeiten.

Munin selber ist als Master/Client-Anwendung aufgebaut. Der Master-Rechner kann den „Munin-Node“ auf weiteren Rechnern im Netzwerk abfragen und so diese Informationen mit anzeigen. Munin eignet sich daher für die Überwachung eines einzigen Rechners wie auch für die Überwachung eines ganzen Rechnerparks. Ein Beispiel einer Munin-Installation zur Überwachung eines ganzen Rechnerfuhrparks findet man hier.

Munin kann bei allen gängigen Linux Distributionen aus den Paketquellen installiert werden. Dazu müssen je nach Bedarf die Pakete munin und munin-node installiert sein. Je nach Einsatz sollte nur eines der beiden Pakete installiert werden. munin-node sammelt nur die Daten, die dann von munin abgerufen und über einen Webserver dargestellt werden.

Bei der Installation von Munin ist zu beachten, dass ein Webserver auf dem Rechner bereits eingerichtet sein sollte, damit die Informationen auch abgerufen werden können. Informationen hierzu findet man in den Dokumentationen der genutzten Linux-Distribution. Für Ubuntu findet man im Wiki von ubuntuusers.de die benötigten Infos.

Anschließend kann man Munin sofort über die URL http://serverip/munin erreichen. Wie alle anderen Dienste bringt Munin Start/Stop-Skripte mit. Diese Skripte lassen sich natürlich auch zum Kontrollieren des Dienstes gebrauchen.

$ sudo /etc/init.d/munin-node {start|stop|restart|force-reload|try-restart}

• start — Startet den Dienst.
• stop – Stoppt den Dienst.
• restart — Startet den Dienst neu, bestehende Verbindungen auf den Server werden gekappt.
• force-reload -- Lädt die Konfigurationsdateien neu und beendet laufende Verbindungen.
• try-restart — Startet den Dienst nur neu, wenn er vorher nicht beendet wurde.

Munin und Munin-Node können nun getrennt voneinander eingerichtet werden. Die Konfiguration erfolgt jeweils über eine Textdatei, die mit einem beliebigen Texteditor sowie Root-Rechten bearbeitet werden kann. Zuerst wie die Konfiguration von Munin selber beschrieben.

Munin

Munin ruft die Informationen der einzelnen Nodes ab und stellt die gewonnen Informationen über einen Webserver dar. Die Konfiguration erfolgt über die Datei /etc/munin/munin.conf. In der Standardeinstellung wird nur der „localhost“, also der eigene Rechner von munin abgefragt.

# a simple host tree
[localhost.localdomain]
    address 127.0.0.1
    use_node_name yes

Hier kann man jedoch problemlos weiter Munin-Nodes hinzufügen. Also beispielsweise einfach

[webserver.beispiel]
    address 192.168.0.10
[sqlserver.beispiel]
    address 192.168.0.11

in die Konfigurationsdatei einfügen.

Munin kann beim Überschreiten festgelegter Werte automatisch Warnungen verschicken. So wird man als Administrator rechtzeitig gewarnt, wenn beispielsweise Festplatten überlaufen zu drohen. Dazu muss in der munin.conf erst einmal der Empfänger mittels den Zeilen…

# Drop somejuser@fnord.comm and anotheruser@blibb.comm an email everytime
# something changes (OK -> WARNING, CRITICAL -> OK, etc)
contacts me
contact.me.command mail -s "Munin notification ${var:host}" email@foo.bar
contact.me.always_send warning critica

…installiert und konfiguriert ist. Anschließend kann man die kritischen Werte definieren, bei denen die Warnung abgeschickt werden soll. Dies geschieht bei jedem einzelnen Host in der Art

[localhost.localdomain]
    address 127.0.0.1
    use_node_name yes
    <plugin>.<feldname>.{critical,warning} <wert>

Hierbei sind für die Platzhalter zu ersetzen:

• plugin – Den Namen des Plugins bekommt man am einfachsten über die URL des Graphen. Am Ende der URL findet man den Namen wie z.B. beim Plugin zur Festplattenbelegung …/localhost.localdomain-df.html. Das „df“ wäre in diesem der Pluginname.
• feldname – Die Feldnamen erfährt man wiederum, wenn man sich einen Graphen im Detail ansieht. Auf diesen Seiten sind am Ende die Feldnamen unter der Bezeichnung „Internal name“ aufgeführt.
• critical,warning – Diese beiden Optionen sind frei wählbar und bestimmt ob eine „Warnung“ oder eine „Kritische Warnmeldung“ verschickt wird.
• wert – Dieser Wert ist frei wählbar und sollte entsprechend dem Wert gesetzt werden, ab wann die Warnung verschickt werden soll.

Letztendlich sieht dann ein Eintrag beispielsweise so aus:

[localhost.localdomain]
    address 127.0.0.1
    use_node_name yes
    df._dev_evms_hda2.warning 70
    df._dev_evms_hda2.critical 95
    df._dev_mapper_hda5.warning 70
    df._dev_mapper_hda5.critical 70

Munin-Node

Der Munin-Node sammelt Daten über das System. In der Konfigurationsdatei /etc/munin/munin-node.conf gibt es wiederum auch nicht allzu viel einzustellen. Die wichtigste Option ist sicherlich die Möglichkeit, dass der Node von einem anderen Munin-Client abgefragt wird. Die Standardeinstellung limitiert die Abfrage auf den „localhost“, weitere Nodes müssen so wie beispielsweise hier…

# A list of addresses that are allowed to connect.  This must be a
# regular expression, due to brain damage in Net::Server, which
# doesn't understand CIDR-style network notation.  You may repeat
# the allow line as many times as you'd like

allow ^127.0.0.1$
allow ^192..168.0.5$

…hinzugefügt werden. Von Haus aus sind zahlreiche Plugins aktiviert. Im Verzeichnis /usr/share/munin/plugins findet man nach weitere Module, die man bei Bedarf hinzufügen kann. Prinzipiell geschieht dies durch das Setzen eines Links in das Verzeichnis /etc/munin/plugins/. Alle Plugins, die dort verlinkt sind, werden von Munin-Node beachtet. Es gibt zwei spezielle Arten von Plugins. „Autoconf“ und „Wildcard“-Plugins. Die meisten Plugins konfigurieren sich selber. Über den Befehl…

$ ./<plugin> autoconf

…kann man überprüfen, ob das Modul die Funktion autoconf beherrscht, also nicht konfiguriert werden muss. Ist die Antwort yes, so kann man das Modul ohne weitere Probleme aktivieren. Dazu später mehr. Wildcard Plugins erkennt man daran, dass sie einen Unterstrich „_“ am Ende des Dateinames wie if_ oder sensors_ tragen. Diese Plugins können mehrere Geräte überwachen und benutzen die Angabe nach dem Unterstrich als Variable. Über die Option suggest bekommt man Informationen zu den Möglichkeiten:

$ ./<plugin>_ suggest

Bevor man ein Plugin aktiviert, sollte man es kurz testen. Dazu gibt es das Kommando munin-run. Dieses führt das Plugin aus und zeig die Ergebnisse in einem Terminal an.

$ munin-run <plugin>
_dev_evms_hda2.value 50
varrun_var_run.value 1
varlock_var_lock.value 1
procbususb.value 1
udev_dev.value 1
devshm_dev_shm.value 0
lrm_lib_modules_2_6_20_16_generic_volatile.value 11
_dev_mapper_hda1.value 57
_dev_mapper_hda5.value 78

So kann man frühzeitig erkennen, ob das Plugin funktioniert und ob Daten ausgegeben werden. Wie schon gesagt müssen die Plugins aus /usr/share/munin/plugins nur in /etc/munin/plugins/ verlinkt sein, um aktiviert zu werden. Dies geschieht bei einem normalen Plugin in einem Terminal mittels des Befehls…

$ sudo ln -s /usr/share/munin/plugins/ /etc/munin/plugins/

Bei einem Wildcard-Plugin muss man noch die zu übermittelnde Option hinzufügen…

$ sudo ln -s /usr/share/munin/plugins/_ /etc/munin/plugins/_

Nachdem man ein Plugin aktiviert hat, muss man den Munin-Node neu starten, damit das Plugin auch berücksichtigt wird.

Beispiele

Beispiel 1

Munin kann die Daten, die die Programme Lm sensors sowie hddtemp liefern, einbinden. Sind die Programme bei der Installation von Munin-Node bereits installiert, so wird dies meist erkannt und das Plugin aktiviert. Möchte man dies nachholen, so müssen die entsprechenden Programme installiert und dann die Plugins mittels der folgenden Befehle aktivieren werden.

$ sudo ln -s /usr/share/munin/plugins/sensors_ /etc/munin/plugins/sensors_fan
$ sudo ln -s /usr/share/munin/plugins/sensors_ /etc/munin/plugins/sensors_volt
$ sudo ln -s /usr/share/munin/plugins/sensors_ /etc/munin/plugins/sensors_temp

Beispiel 2

In den Standardeinstellungen werden nur die Netzwerkschnittstellen „eth0“ und „eth1“ abgefragt. Besitzt der Rechner eine Anbindung über WLAN oder nutzt eine Einwahlleitung, so kann man diese überwachen lassen.

$ sudo ln -s /usr/share/munin/plugins/if_ /etc/munin/plugins/if_
$ sudo ln -s /usr/share/munin/plugins/if_err_ /etc/munin/plugins/if_err_

Beispiel 3

Auch verschiedene Serverdienste lassen sich abfragen. So z.B. auch der Webserver Apache. Dieser muss jedoch noch so konfiguriert werden, dass er Informationen über seinen Zustand bereitstellt. Dies geschieht in der Konfigurationsdatei /etc/apache/apache2.conf. Hier müssen die Kommentare beim Modul mod_status entfernt und noch ExtendedStatus On eingetragen werden, so dass der Abschnitt am Ende so aussieht:

<IfModule mod_status.c>
    #
    # Allow server status reports generated by mod_status,
    # with the URL of http://servername/server-status
    # Change the ".example.com" to match your domain to enable.
    #
    ExtendedStatus On
    <Location /server-status>
        SetHandler server-status
        Order deny,allow
        Deny from all
        Allow from 127.0.01
    </Location>
</IfModule>

Damit die Änderung aktiv wird muss Apache neu gestartet werden. Nun kann man die Munin-Plugins für Apache aktivieren und Munin zeigt die Zugriffszahlen des Apache Servers an.

$ sudo ln -s /usr/share/munin/plugins/apache_accesses /etc/munin/plugins/
$ sudo ln -s /usr/share/munin/plugins/apache_processes /etc/munin/plugins/
$ sudo ln -s /usr/share/munin/plugins/apache_volume /etc/munin/plugins/

*** Looking up your hostname...
*** Checking ident
*** No identd (auth) response
*** Found your hostname
Welcome to the freenode IRC Network IRCNICK
...

An der Zeile No identd (auth) response erkennt man, dass der IRC-Server keine ident Antwrt bekommen konnte. Um diesen Vorgang zu beschleunigen kann man seinen eigenen identd-Server auf dem NAT-Router einrichten. Unter Ubuntu kann man sehr einfach diesen Server einrichten. Dazu muss nur das Paket gidentd installiert werden. Eine Konfiguration des identd ist nicht nötig. Ist der identd gestartet…

$ sudo /etc/init.d/gidentd start

…so sieht das Einloggen auf einem IRC-Server so aus:

*** Looking up your hostname...
*** Found your hostname, welcome back
*** Checking ident
Welcome to the freenode IRC Network IRCNICK
...

Man sieht, die obige Meldung ist verschwunden und das Einloggen geht deutlich schneller. Es ist nocht zu beachten, dass der Port TCP 113 in einer Firewall freigeschaltet sein muss. Sonst kann der identd nicht seiner Aufgabe nachkommen.

So wäre es in der Theorie möglich, durch einen Brute-Force-Angriff einen Account mit einem gültigen Passwort zu treffen. Denn der SSH-Server selber ist sehr geduldig mit einem Angreifer. Dieser könnte über Stunden, Tage oder gar Wochen hinweg immer und immer wieder Accountnamen und Passwörter wiederholt austesten.

Hier kommt der kleine Dienst Fail2Ban ins Spiel. Versucht sich jemand per SSH einzuloggen und misslingt dieser Versuch, so trägt sshd — also der SSH-Server — dieses Ereignis in die Logdatei /var/log/auth.log ein.

Oct 14 20:13:11 knecht sshd[25218]: Failed password for root from 192.168.0.251 
port 43101 ssh2

Fail2Ban überwacht nun die auth.log im Hintergrund und blockiert die Zugriff zum SSH-Server über iptables, falls der Zugriff per SSH über eine IP wiederholt scheitert. In der Datei /var/log/fail2ban.log protokolliert Fail2Ban das Ereignis mit …

2006-10-14 20:13:12,132 INFO: SSH: 192.168.0.251 has 5 login failure(s). Banned.
2006-10-14 20:13:12,132 WARNING: SSH: Ban 192.168.0.251

Fail2Ban ist ist den Ubuntu Paketquellen (universe) vorhanden und kann direkt installiert werden. Hat man das Paket installiert, können man über die Konfigurationsdatei /etc/fail2ban.conf noch Einstellungen vorgenommen werden. Aber eigentlich ist die Standardkonfiguration ausreichend. Hat man die fail2ban.conf geändert, so muss man den Dienst mit…

$ sudo /etc/init.d/fail2ban restart

…neu starten, damit die Änderungen eingelesen werden. Der Dienst ist gleich nach der Installation des Paketes aktiv und blockiert nach dem fünften vergeblichen Versuch einer IP sich einzuloggen den Zugriff dieser IP zum SSH-Server.