Ferngesteuert

Kennen Sie das? Sie erhalten um 21.30 Uhr einen Anruf von einem Bekannten. Der Computer geht nicht, aber der Bekannte braucht den PC natürlich noch ganz dringend. Auf die Frage, was denn nicht ginge, erhalten Sie die Auskunft: "Der Knopf ist weg", was wiederum die Frage provoziert: "Welcher Knopf?" Antwort: "Der der sonst immer unten links ist!".

So oder so ähnlich beginnen die meisten Anfragen im privaten Umfeld. Selbige enden dann meist mit einer Autofahrt zum Bekannten und der Suche nach dem Knopf, der sonst immer unten links ist. Während der Fahrt kommt einem meist der Gedanke, dass das irgendwie anders gehen müsste. Lösungen für Remote-Support gibt es ja zu genüge, aber im entscheidenden Moment versagen diese aus verschiedenen Gründen.

Einer der häufigsten Hinderungsgründe liegt in NAT-Routern, hinter denen sich heute viele PCs verbergen. Diese verhindern den direkten Zugriff auf die Maschine des anderen, selbst wenn Sie die IP wüssten. Wenn der Anruf eingeht, ist es zudem zu spät am Router des Bekannten ein Portfowarding einzurichten, DynDNS konfigurieren, einen VNC-Server auf dem Rechner aktivieren oder auch einfach eine VPN-Verbindung zu starten.

Der Umbau wäre komplex und zöge massive Eingriffe ins Netzwerk des Bekannten nach sich. Offene Ports und Verbindungen, die im Normalfall unnötig sind, wären die Folge. Schöner wäre es, wenn Sie dem Bekannten, bei Anruf, einfach eine Datei zu kämen ließen, die die notwendigen Änderungen durchführt und den Zugriff vom eigenen PC auf den des Bekannten erlaubt.

Hilfe mit Bordmitteln

Glücklicherweise liefern aktuelle Distributionen alles mit, was Sie dafür benötigen. Die notwendigen Programme brauchen Sie nur noch richtig zusammensetzen. Doch zuerst ein Überblick, wie das Ganze funktioniert: Abbildung 1 zeigt die Netzwerkstruktur mit einem PC hinter einem Router mit Firewall. Sie bildet das in privaten Haushalten übliche Szenario ab. Sowohl Supporter als auch Benutzer haben einen normalen Desktoprechner auf dem eine aktuelle Distribution mit Gnome oder KDE läuft und sind über einen kleinen DSL-Router ans Internet angebunden.

Abbildung 1: Eine typische Netzwerktopologie bei einem Anwender, der mit einem Router über einen DSL-Anschluss ins Netz geht.

Die Idee ist Folgende: Sie aktivieren auf dem Rechner des Bekannten einen VNC-Server. Anschließend bauen Sie einen Reverse-SSH-Tunnel vom Rechner des Bekannten zum eigenen Rechner auf und leitet somit den Port, auf dem der VNC-Server hört, auf den eigenen Rechner um. Danach verbinden Sie sich mit einem VNC-Client Server und steuern so den Rechner des Bekannten (Abbildung 2).

Abbildung 2: Mittels SSH und VNC haben Sie direkten Zugriff auf einen anderen Rechner über eine sichere Verbindung.

Alles, was Sie dazu auf der Gegenseite benötigen, ist ein VNC-Server, einen SSH-Client und ein Shell-Skript, das die beiden ersten Programme richtig konfiguriert. Die beiden ersten Teile finden Sie problemlos in den Repositories jeder gut sortierten Distribution. Als VNC-Server kommt entweder Vino (Gnome) oder KRFB (KDE) in Frage; als SSH-Client einfach das SSH-Kommando. Auf ihrem Rechner brauchen Sie einen VNC-Client, einen SSH-Server und eine bekannte – aber nicht unbedingt feste – IP-Adresse.

Ports weiterleiten

Zuerst konfigurieren Sie Ihr Netzwerk, so dass der SSH-Client der Gegenseite in der Lage ist, eine Verbindung herzustellen. Dazu ermitteln Sie zuerst die öffentliche IP-Adresse Ihres Rechners. Im Web existieren diverse Seiten, die Ihnen die IP-Adresse verraten – unter anderem http://checkip.dyndns.org. Notieren Sie sich die IP. Sie brauchen sie später. Praktisch ist in diesem Zusammenhang auch ein kostenloser DynDNS-Account. Dann kommt im Shell-Skript die DynDNS-URL statt der IP zum Einsatz, und Sie brauchen das Skript nicht jedes mal neu erstellen. Im Beispiel nehmen wir einfach an, dass uns der DynDNS-Account linuxuser.dyndns.org zur Verfügung steht.

Als nächstes ändern Sie gegebenenfalls die Konfiguration des Routers so, dass dieser den TCP-Port 22 auf den Port 22 Ihres PCs weiterleitet. Aktuelle Hardware, die die Provider zum DSL-Anschluss mitliefern, beherrschen in aller Regel dieses Feature. Leider bezeichnen die Hersteller die Funktion immer unterschiedlich. Mal spricht das Handbuch von Portforwarding, mal von Exposed Host, mal von Virtual Server.

Haben Sie diese Hürde genommen, richten Sie den Rechner ein. Dafür benötigen Sie einen SSH-Server, in der Regel OpenSSH, und ein Benutzerkonto, das Sie für den Reverse-SSH-Tunnel verwenden. Sofern die Distribution keinen Server vorinstalliert hat, holen Sie dies über die Paketverwaltung nach. Unter Ubuntu, Debian und dessen Derivaten funktioniert das über sudo apt-get install openssh-server. Bei OpenSuse hilft YaST und dessen Softwareverwaltung weiter.

Wenn Sie sowieso gerade Software installieren, ziehen Sie am besten gleich einen VNC-Client nach. Bei KDE eignet sich das Programm KRDC recht gut, da es einen passablen Vollbildmodus hat. Prinzipiell tut es aber auch jeder VNC-Client. Die Installation von KRDC erledigen Sie unter Ubuntu und Debian mittels sudo apt-get install krdc; bei OpenSuse hilft wieder YaST weiter.

SSH-Server

Nun geht es an die Konfiguration des SSH-Servers. Dieser muss in der Lage sein Benutzer anhand eines Public-Keys zu identifizieren. Dazu passen Sie die Datei /etc/ssh/sshd_config von root an. Suchen Sie die Variable PubkeyAuthentication. Diese setzen Sie auf yes. Finden Sie keine entsprechende Variable, fügen Sie einfach die entsprechende Zeile hinzu. Anschließend starten Sie den SSH-Server als root mit /etc/init.d/ssh restart neu.

Nun erstellen Sie noch einen Benutzer. Dies heißt, der Eingängigkeit wegen, remotesupport. Der Name spielt aber eigentlich keine Rolle. Um den Benutzer anzulegen, geben Sie einfach in einem Terminal als root den Befehl useradd -m -d /home/remotesupport -s /bin/false remotesupport ein. Anschließend braucht der Benutzer ein Passwort und ein Schlüsselpaar für den Zugang. Das Passwort legen Sie als Administrator mittels passwd -l remotesupport an.

Um den Schlüssel zu generieren, wechseln Sie am einfachsten mittels su - remotesupport in den Account und rufen dann ssh-keygen auf. Damit generieren Sie das Schlüsselpaar. Anschließend sorgen Sie noch mit cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys dafür, dass der Server den Schlüssel erkennt.

Client-Konfiguration

Nun geht es an die Konfiguration des Clients. Aufmerksame Leser wenden an dieser Stelle wahrscheinlich ein, dass eigentlich keine Modifikationen am Client der Gegenseite notwendig seien. Das stimmt nur halb, denn die Änderungen sind nicht dauerhaft. Sie stellen temporär einige Parameter um. Das Umstellen könnte natürlich auch der Benutzer des Clients selbst machen. Allerdings besteht die Gefahr, dass sich dabei Fehler einschleichen. Also erstellen Sie ein kleines Skript, das die Modifikationen vornimmt.

Das Shell-Skript sorgt für den Aufbau des SSH-Tunnels. Dazu braucht es ein Setup, mit dem sich der Client am Rechner des Supporters ohne Passwort und ohne weiteres Zutun des Benutzers anmeldet, um einen Reverse-SSH-Tunnel zu öffnen. Das Kommando für den Tunnel lautet: ssh -i $PREFIX/privatekey -N remotesupport@linuxuser.dyndns.org -R 10283:localhost:5900 -R 10285:localhost:22.

Das -R ist der entscheidende Teil. Mit diesem Schalter bittet der SSH-Client beim Server um eine Weiterleitung. Der Server hört dann auf den Port 10283 und leitet alle Daten, die die Gegenstelle dorthin schreibt, durch den SSH-Tunnel zu Port 5900 des Clients. Somit gelangen später die Anfragen des VNC-Clients des Supporters an den VNC-Server des Benutzers.

Das Schöne dabei ist, dass die spätere VNC-Kommunikation, dank SSH gleich verschlüsselt abläuft. Der zweite Schalter -R baut übrigens einen zweiten Tunnel auf, welche den Port 10285 auf den eventuell vorhandenen SSH-Server des Clients weiterleitet. Das wäre zwar im Prinzip nicht notwendig. Es erleichtert aber unter Umständen die Arbeit, wenn Sie neben dem VNC-Zugang auch Zugriff per Konsole haben.

Das alleine reicht jedoch noch nicht. Das SSH-Kommando würde sich beschweren, dass es den anderen Host noch nicht kennt und es Key privatekey nicht findet. Also konfigurieren Sie das System so umkonfigurieren, dass es den Host bereits kennt. Dazu fügen Sie den Hostkey des Remotehosts sich in der Datei ~/.ssh/know_hosts ein. Mit dem Kommando SSH-Scankeys bewerkstelligen Sie das ganz leicht (Listing 1).

Fehlt noch der passende private Schlüssel. Diesen legen Sie ebenfalls auf dem Client ab. Das Shell-Skript muss diesen Schlüssel also gleich mitliefern. Haben Sie, wie oben angegeben, einen neuen Account auf Ihrem Rechner für die Support-Arbeiten angelegt, wechseln Sie zuerst in diesen, um den Schlüssel auszugeben. Haben Sie die wichtigen Bestandteile zusammengetragen, dann brauchen Sie noch ein paar zusätzliche Befehle und der erste Teil des Skripts sieht aus wie in Listing 1.

#! /bin/bash
# Ein Arbeitsverzeichnis erstellen zum Ablegen temporärer Daten.
PREFIX=/tmp/remotesupport
mkdir $PREFIX
# SSH Verzeichnis erstellen, sofern es noch nicht existiert.
if [ ! -f ~/.ssh/known_hosts ]; then
mkdir ~/.ssh
chmod 0700 ~/.ssh
fi
# Datei known_hosts sichern zum späteren Wiederherstellen.
cp ~/.ssh/known_hosts $PREFIX/known_hosts
# Serverschlüssel kopieren.
ssh-keyscan -t dsa linuxuser.dyndns.org >> ~/.ssh/known_hosts
ssh-keyscan -t rsa linuxuser.dyndns.org >> ~/.ssh/known_hosts
# Privaten Schlüssel aus dem Skript schreiben.
# Alles bis zwischen den EOFs landet in der Ausgabedatei.
# Der Schlüssel hier ist stark gekürzt!
cat > $PREFIX/privatekey << EOF
—--BEGIN RSA PRIVATE KEY—–
MIIEoQIBAAKCAQEAslldf1zZJ3+e6sAVmpY4IeV886hlv+qnLjE12tFqJyiKCgWd
7NEfdDMOdCB6mlSt/v7JGbbFKFvJNHUq7xjp/bS1NBbZ6xxhDci7Sw7w+0QGbqQM
8i13BnszuqY1GHlpeMWulLXcS+aWhcPrDcVPE44Ud+mrc6gWhhc6hJDbkK5Zt4hM
mmyVPx0I+jrglzrjGHaObWw6BQ9MuQ/hXrepeRV61EMl1z3P/rs+N0muhTBnfAvN
0hlEpaBFHyknOS30fUGkV2hm1Ci4X+oxCLtQ0VwFKUNopgak167nJ4/wgbfHgslZ
XMsCgYAzv51fzIXWg13Lli6KgceoF2It1YxetRh6WctfpgsVos7Cwiqr+pdJfIkL
Jk/DBdkhWQEpBr/aUivpWWg7LWkXeBexkLd8oggGwe9wvTasGG13uIEVSvxRXdWK
A36AjwdxdhmWHKz3DftlqOHpi/q0zWvsbyMzCOzG5iNhoO9WGw==
—--END RSA PRIVATE KEY—–
EOF
# Zugriffsrechte richtig setzen.
chmod 0600 $PREFIX/privatekey
# SSH-Verbindung öffnen.
ssh -i $PREFIX/privatekey -N remotesupport@linuxuser.dyndns.org -R 10283:localhost:5900 -R 10285:localhost:22 &

Im nächsten Abschnitt des Skripts starten Sie den VNC-Server, damit Sie wirklich Zugriff auf den Desktop des Benutzers bekommen. Sowohl KDE als auch Gnome liefern standardmäßig einen VNC-Server mit. Dieser ist weder aktiviert noch eingerichtet. Leider nutzen KDE und Gnome unterschiedliche VNC-Server. Daher testen Sie zunächst, welchen von Beiden Sie verwenden. Dazu prüft Sie einfach, welches der beiden Programme Vino-preferences oder KRFB sich im System findet. Listing 2 zeigt den passenden Teil des Skripts.

ISTGNOME=`which vino-preferences | wc -l`
ISTKDE=`which krfb | wc -l`
# Wir haben einen Gnome-Desktop!
if [ $ISTGNOME -eq 1 ]; then
# Aktuelle Einstellungen sichern.
gconftool-2 --dump /desktop/gnome/remote_access > $PREFIX/vino_set
# Neue Einstellungen setzen.
gconftool-2 -s -t bool /desktop/gnome/remote_access/enabled true
gconftool-2 -s -t bool /desktop/gnome/remote_access/local_only false
gconftool-2 -s -t bool /desktop/gnome/remote_access/prompt_enabled false
gconftool-2 -s -t bool /desktop/gnome/remote_access/view_only false
fi
# Wir haben einen KDE-Desktop!
if [[ $HAVEVINO -eq 0 && $HAVEKRFB -eq 1 ]]; then
# Aktuelle Einstellungen sichern.
cp ~/.kde/share/config/krfbrc $PREFIX/krfbrc_set
# Neue Einstellungen setzen.
cat > ~/.kde/share/config/krfbrc << EOF
allowDesktopControl=true
allowUninvited=true
confirmUninvitedConnection=false
disableBackground=true
disableXShm=false
enableSLP=false
preferredPort=5900
uninvitedPasswordCrypted=
[invitations]
invitation_num=0
EOF
# Der krfb muss einmal kurz gestartet werden, damit
# die Änderungen übernommen werden. Der Benuzter sieht
# dabei ein kleines Fenster welches sich nach einer Sekunde
# wieder schließt. Sollte nicht weiter tragisch sein :-)
krfb &
sleep 1
killall krfb
fi

Damit wäre das Skript im Prinzip schon fertig. Die Verbindung steht, der VNC-Server startet und Sie verbinden sich mit Ihrem VNC-Client auf die Adresse localhost:10283 und sehen danach – hoffentlich – den Desktop des anderen Benutzers. Aber der Ordnung halber erweitern wir das Skript noch ein wenig, so dass es aufräumt, sobald sich der SSH-Tunnel schließt. Dafür geht das Skript in eine Warteschleife, bis sich der Tunnel schließt (Listing 3).

SSHRUNNING=`ps ax | grep 'ssh -i $PREFIX/privatekey -N remotesupport@linuxuser.dyndns.org -R 10283:localhost:5900 -R 10285:localhost:22' | grep -v grep | wc -l`
while [ $SSHRUNNING -gt 0 ]; do
     SSHRUNNING=`ps ax | grep 'ssh -i $PREFIX/privatekey -N remotesupport@linuxuser.dyndns.org -R 10283:localhost:5900 -R 10285:localhost:22' | grep -v grep | wc -l`
     sleep 3
done

Zur Erklärung: Dieser Teil des Skript durchsucht die Prozessliste nach dem Tunnelprozess. Findet sich eine entsprechende Zeile, wartet das Skript drei Sekunden, bevor es erneut nach dem Prozess sucht. Findet es keinen Prozess, beendet sich die Schleife und das Skript läuft weiter. Nach der Schleife fehlt jetzt nur noch die Aufräumarbeit (Listing 4).

# Datei known_hosts wiederherstellen.
mv $PREFIX/known_hosts ~/.ssh/known_hosts
# VNC-Einstellungen wiederherstellen.
if [ $ISTGNOME -eq 1 ]; then
gconftool-2 --load $PREFIX/vino_set
fi
if [[ $ISTGNOME -eq 0 && $ISTKDE -eq 1 ]]; then
mv $PREFIX/krfbrc_set ~/.kde/share/config/krfbrc
krfb &
sleep 1
killall krfb
fi
# Temporäres Verzeichnis aufräumen.
rm -rf $PREFIX

Damit wäre das Skript fertig. Sie speichern es einfach unter dem Namen support.sh ab. Braucht jemand Ihre Unterstützung, schicken Sie dem Betreffenden einfach diese Datei. Der Benutzer braucht das Skript nur noch ausführbar zu machen, was er über die Kontextmenüs von Nautilus und Konqueror bequem erledigt. Anschließend reicht ein Doppelklick und schon ist der Weg frei für den Helfenden.

Abbildung 3: Mit einem einfachen Klick machen Sie das Skript unter Gnome ausführbar.

Ein Hinweis noch: Nach getaner Arbeit sollte Sie auf Ihrem PC den Benutzer remotesupport wieder sperren und das Portforwarding abschalten. Andernfalls wäre der PC von außen erreichbar und eventuell ein Angriffsziel.

Fazit

Im Prinzip fehlen jetzt nur noch drei Dinge. Erstens wäre es schön, wenn Sie den Remotesupport auch für Windows anbieten könnten, denn das Betriebssystem kommt ja hin und wieder zum Einsatz. Zweitens wäre es gut, wenn Sie eine Live-CD hätten, die sich fernsteuern ließe. Drittens wäre es nett, wenn Sie das Skript nicht selbst schreiben müssten, sondern ein kleines Programm haben, welches die notwendigen Daten sammelt und es dann für Linux, als Executeble für Windows sowie in einer LiveCD erstellt.

Haben Sie die DVD-Ausgabe in der Hand, dann schauen Sie einfach mal auf dem beigelegten Datenträger nach – da finden Sie die entsprechende Dateien. Sollte im Übrigen auf Ihrem PC wider erwarten Windows laufen, tut das der Sache keinen Abbruch. Sie brauchen dafür nur einen SSH-Server, wie er zum Beispiel über Cygwin [4] erhältlich ist.