Fernwartung von Linux-Maschinen

Diese Seite soll einen Einblick darüber geben, welche Möglichkeiten bestehen, Linux-Maschinen per sicherem Remote-Zugriff zu bedienen, d.h. ohne wirklich vor der eigentlichen Maschine zu sitzen. Dies kann erforderlich sein, bei Maschinen, die weder Bildschirm noch Tastatur besitzen, bei denen durch einen Hardware- oder Softwarefehler die Bedienung per Bildschirm und/oder Tastatur nicht mehr möglich ist oder auch einem Hilfesuchenden aus der Ferne unter die Arme zu greifen. Es soll hier kein umfassender Abriss aller möglichen Optionen gegeben werden. Vielmehr soll ein schneller Einstieg in die Welt des Remote-Zugriffs vermittelt werden. Für weiterführende Informationen empfehle ich, die Manpages der angeführten Programme zu lesen.

Fernzugriff über ssh

Die ersten Schritte zum Thema Fernzugriff auf Rechner wurden mit dem Telnet-Protokoll gemacht. Dieses hat jedoch den entscheidenden Nachteil, dass die Übertragung sämtlicher Daten im Klartext stattfindet. In einer abgeschotteten Netzwerkumgebeung mag das ja noch angehen. Hier soll es aber um einen sichere Übertragung der Daten u.U. auch über das Internet gehen. Da kommt ssh (secure shell) zum Zuge.

Einrichtung auf dem Server

Auf der Maschine, auf die der Fernzugriff erfolgen soll, muss das Paket openssh-server installiert sein. Ich selbst erledige das immer gleich beim Aufsetzen des Systems. So hat man wenigstens noch einen Zugriff auf die Maschine, wenn nach dem ersten Start der X-Server aus irgendeinem Grund nicht so läuft, wie es sein sollte und dadurch die Bedienung blockiert ist. Die zuständige Konfigurationsdatei ist /etc/ssh/sshd_config. Hier sollten einige wichtige Einstellungen vorgenommen werden. Ich gehe hier nur auf die Einstellungen ein, die entgegen den Voreinstellungen geändert werden können bzw. sollten. Alle nicht erwähnten Einstellungen können auf den Vorgabewerten belassen werden.

Port - der Port auf dem der ssh-Server lauscht - im Normalfall Port 22

LoginGraceTime - Zeit nach der der Server die Verbindung unterbricht, wenn kein Login erfolgt ist.

MaxAuthTries - maximale Anmeldeversuche am Server - ist die Hälfte davon erreicht, werden alle weiteren Versuche mitgeloggt.

PermitEmptyPasswords - erlaube Zugriff mit leerem Passwort - sollte keinesfalls auf yes stehen.

PermitRootLogin - erlaube Root-Zugriff - hier kann man mit no den Zugriff für Root generell verweigern.

X11Forwarding - mit yes wird die X11-Weiterleitung erlaubt und damit das Starten von GUI-Programmen.

DenyUsers - eine Liste von Usernamen denen der Zugriff auf den Server verboten ist. Kann auch in der Form USER@HOST angegeben werden. Dann wird sowohl Username als auch der Host verglichen.

AllowUsers - eine Liste von Usernamen, denen der Zugriff auf den Server erlaubt ist. Kann auch in der Form USER@HOST angegeben werden.

Die beiden letzten Optionen werden übrigens in der Reihenfolge Deny - Allow abgearbeitet. Hier haben wir auch die Möglichkeit den Root-Zugriff etwas feiner einzustellen. Wir können z.B. PermitRootLogin auf yes lassen und bei AllowUsers mit root@mein_rechner den Zugriff für Root vom Host mein_rechner erlauben. Für alle anderen Rechner ist der Root-Zugriff dann verboten.

Nach dem Anpassen der Konfigurationsdatei muss der ssh-Server mit

/etc/init.d/ssh restart

neu gestartet werden.

Einrichtung auf dem Client

Auf dem Client muss das Paket openssh-client installiert sein. Die zugehörige Konfigurationsdatei ist /etc/ssh/ssh_config. Sie ist schon mit sinnvollen Werten belegt, so dass wir sofort loslegen können.

Um uns mit einem SSH-Server zu verbinden geben wir also in einem Terminal

ssh username@server

ein. Username ist dabei ein auf dem Server existierender User und server ist entweder der in der Datei /etc/hosts bekannt gemachte Hostname oder die IP-Adresse des Servers. Sind die Usernamen auf Client und Server identisch, reicht auch ein

ssh server

Ist die Verbindung aufgebaut, wird man nach dem zugehörigen User-Passwort gefragt und nachdem dieses eingegeben ist, befindet man sich auf der entfernten Maschine. Greift man zum ersten Mal auf einen SSH-Server zu, bekommt man die Meldung, dass die Authentizität des Servers nicht festgestellt werden konnte. Gleichzeitig wird einem der Fingerabdruck des Server-Schlüssels mit der Frage präsentiert, ob man sich sicher ist, zu diesem Rechner einen Verbindung aufbauen zu wollen und damit den Server in die Liste der bekannten Hosts einzutragen. Im eigenen Netzwerk sollte das kein Problem sein. Bei fremden Servern sollte man sich aus Gründen der Sicherheit vorher vom Adminsitrator den Fingerabdruck des Servers übermitteln lassen, um ihn mit dem beim Verbindungsaufbau übermittelten Fingerabdruck vergleichen zu können. Auf dem Server kann man sich den Fingerabdruck mit dem Befehl

ssh-keygen -f /etc/ssh/ssh_host_rsa_key.pub -l

anzeigen lassen.

Ist der öffentliche Schlüssel des Servers erst einmal in der Datei ~/.ssh/known_hosts abgelegt, wird bei weiteren Verbindungen durch asymetrische Kryptografie sichergestellt, dass der Server auch den zugehörigen privaten Schlüssel besitzt. Anderenfalls wird die Verbindung abgebrochen.

In einer ssh-Sitzung haben wir die gleichen Rechte und können die gleichen Befehle verwenden, als wenn wir direkt auf der Konsole des betreffenden Rechners arbeiten. Alle Konsolenprogramme, die auf dem entfernten Rechner installiert sind, können wir auch über ssh ausführen. Wir können aber auch dem ssh-Befehl gleich einen auszuführenden Befehl mitgeben.

ssh username@server cat /etc/issue

führt nach dem erfolgreichen Login den Befehl cat /etc/issue aus und beendet danach die ssh-Sitzung automatisch.

Wir können auch GUI-Programme auf dem entfernten Rechner aus der ssh-Sitzung aufrufen. Dazu benutzen wir beim Verbindungsaufbau die Option -X. Nach erfolgreichem Login können wir auf dem Server den Dateimanager Thunar öffnen. Dieser wird dann auf dem Client sichtbar.

user@client:~$ ssh -X user@server
user@server's password: 
Linux server 3.2.0-4-amd64 #1 SMP Debian 3.2.35-2 x86_64

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.
You have mail.
Last login: Thu Jan  3 14:42:06 2013 from 192.168.1.110
user@server:~$ Thunar

Eine ssh-Sitzung wird einfach mit exit beendet.

Fernzugriff über VNC

Virtual Network Computing (VNC) ist eine Software, die den Bildschirminhalt eines entfernten Rechners auf dem lokalen Rechner sichtbar macht und Maus- und Tastaturbefehle vom lokalen Rechner an den entfernten Rechner sendet. Hilfreich kann so etwas sein, wenn die Remote-Verbindung über ssh wegen der Konsole zu kompliziert ist oder aber auch Arbeiten auf der GUI ausgeführt werden sollen, die auf dem entfernten Rechner ebenfalls gesehen werden sollen (Hilfe bei Problemfällen/Schulungen). Programme - auch proprietäre, die nach diesem Prinzip arbeiten, gibt es genug. Hier habe ich mich für x11vnc entschieden. Auch hier benötigt es auf dem entfernten Rechner wieder einen Server und auf dem lokalen Rechner einen zugehörigen Client.

Einrichtung auf dem Server

Auf dem Server muss das Paket x11vnc installiert sein. Einer besonderen Konfiguration bedarf es dabei nicht.

Einrichtung auf dem Client

Auf dem Client muss natürlich eine Clientsoftware für VNC installiert sein. Ich habe mich für das Paket xvnc4viewer entschieden. Denjenigen, denen einen grafische Anwendung mit einer Art Telefonbuch lieber ist, empfehle ich remmina und remmina-plugin-vnc. In beiden Fällen ist keine besondere Konfiguration nötig. Bleiben wir erst einmal bei xvnc4viewer. Um jetzt auf einen entfernten Desktop zugreifen zu können, reicht auf dem lokalen Rechner der Befehl

xvnc4viewer -listen 5500

Damit lauscht der xvnc4viewer auf dem Port 5500 ob ein Server einen Verbindungsaufbau anfragt und damit seinen Desktop freigibt. Dies geschieht einfach auf dem Server mit dem Befehl

x11vnc -scale 9/10 -connect Host

Host kann auch hier sowohl ein in der Datei /etc/hosts bekannt gemachter Rechnername als auch eine IP-Adresse sein. Durch den Parameter scale wird der Desktop auf dem Client mit 9/10 seiner eigentlichen Größe angezeigt. Durch Schliessen des Fensters auf dem Client wird die Verbindung wieder getrennt.

Mehr Komfort

Für jemanden der bei anderen Hilfe in Sachen Linux sucht und dazu seinen Desktop freigeben will, sind Konsolenbefehle - noch dazu solche, die eher selten benutzt werden doch eher ein Graus. Also geben wir doch dem Hilfebedürftigen etwas mehr Komfort an die Hand und erstellen ihm einen Starter auf dem Desktop. Wir öffnen also auf dem Remote-Rechner unseren Lieblingseditor und erstellen einen Datei mit folgendem Inhalt:

[Desktop Entry]
Version=1.0
Encoding=UTF-8
Type=Application
Name=Desktop freigeben für Karl-Heinz
GenericName=Desktop freigeben
Comment=Desktop freigeben
Icon=/usr/share/icons/Tango/24x24/places/network-workgroup.png
Exec=x11vnc -scale 9/10 -connect Host
Terminal=true

Terminal habe ich auf true gesetzt, damit durch das Öffnen eines Terminals wenigsten signalisiert wird, dass ein Fernzugriff läuft. Zu den Bedeutungen der einzelnen Zeilen siehe Einrichtungsdateien. Die Datei speichern wir unter dem Namen remotex.desktop im Heimatverzeichnis des Hilfsbedürftigen im Ordner Desktop.

SSH und VNC über das Internet

Die bis hierher beschriebenen Verfahren eignen sich nur für den Fernzugriff innerhalb des eigenen Netzwerkes. Kommen andere Netzwerke, speziell das Internet ins Spiel, müssen einige zusätzliche Dinge beachtet werden.

1. muss der sich verbindende Rechner (Client) die IP-Adresse oder den Hostnamen vom Server wissen. Bei rein privaten Internetzugängen dürfte das durch die dynamische Zuteilung zwar schwierig aber nicht unmöglich sein. Entweder auf dem Server wird die aktuell gültige IP-Adresse durch Dienste wie z.B. wie_ist_meine_ip oder, wer es mit Bild nicht so hat, auch gerne auf dieser Seite, ermittelt und per Mail oder Telefon an den Client weiter gegeben. Oder der Server versorgt sich über Dienste wie DynDNS mit einem festen DNS-Namen.

2. müssen die an der Übertragung eventuell beteiligten Router speziell auf der Seite des Servers eine Port-Weiterleitung an den Server zulassen. Da die Router diese Funktion in sehr verschiedenen Abschnitten der Konfiguration verstecken, ist es ratsam das Handbuch des jeweiligen Routers zu konsultieren. Häufige Stichpunkte sind Portweiterleitung und Virtuelle Server.

3. müssen auf allen beteiligten Firewalls die entprechenden Ports auch freigeschaltet sein

4. sollten speziell bei SSH-Servern, die 24/7 am Internet hängen der Standard Port 22 auf einen anderen Port umgeleitet werden, siehe Einrichtung auf dem Server. In der Konfiguration der Clients kann dann der entsprechende Port für jeden einzelnen Server eingetragen werden. Außerdem sollte der Zugriff auf den SSH-Server noch schärfer abgesichert werden. Geeignete Massnahmen sind u.a. hier beschrieben.

5. speziell bei der Fernwartung mittels VNC sollte überlegt werden, ob nicht eine Verbindung über einen ssh-Tunnel sinnvoll ist. Dazu wird auf dem eigentlichen Client !, also dem Rechner der auf den entfernten Rechner zugreifen will, ein SSH-Server gestartet. Anschließend wird auf diesem Rechner mit

xvnc4viewer -listen 5500

der VNC-Client gestartet. Auf dem fernzuwartenden Rechner wird nun eine Verbindung mit dem SSH-Server hergestellt und durch diese hindurch eine Verbindung zum vnc-viewer aufgebaut.

ssh -f -L 5500:localhost:5500 hilflos@helfer sleep 10; x11vnc -connect_or_exit localhost:5500

Die ssh-Verbindung läuft dabei im Hintergrund und durch ssh kommt nicht nur mehr Sicherheit ins Spiel, nach dem Schließen des VNC-Viewers wird auch die ssh-Verbindung und der VNC-Server sauber getrennt.

6. muss man darauf gefasst sein, dass die Geschwindigkeit der Verbindung über das Internet natürlich nicht unbedingt so groß ist, wie im lokalen Netzwerk