Linux Helpdesk

Es kommt ja öfter mal vor, dass man (als Linux-User) Freunden, Bekannten oder Kunden per Ferndiagnose mit ihren PC-Problemen helfen will/muss. Wie man das bewerkstelligt beschreibt Chris bei Linux und ich. Die dort angebotene Lösung ist zwar einfach und schnell, hat aber auch Nachteile. Daher möchte ich hier meine Lösung vorstellen.

Mit meiner Lösung ist es möglich über eine verschlüsselte SSH- Verbindung per VNC Unterstützung zu geben, wobei der Hilfesuchende (Client) nichts konfigurieren muss und ruhig hinter einer Firewall sitzen kann (eine 1-click-Lösung). Für die Lösung muss der Rechner des Helfenden (Host) vorbereitet werden, sowie eine ausführbare Datei erstellt werden, die man den clients zur Verfügung stellt.

Ablauf

Bevor ich zur Einrichtung komme, möchte ich erklären, wie der Support abläuft: Der client startet eine (bspw. auf einem Webserver bereitgestellte) .exe-Datei. Diese startet im Hintergrund einen VNC-Server und im Vordergrund ein Terminal. In diesem Terminal wird autom. eine SSH-Verbindung mit dem Host aufgebaut. Über diese Verbindung wird der VNC-Port 5900 zum Host getunnelt. Der Host baut eine VNC-Verbindung mit seinem lokalen Rechner (localhost) auf und sieht den Desktop des remote-Rechners (client).

Host-Vorbereitung

Ich nutze als Beispiel Ubuntu. Die Anmerkungen sind aber natürlich auf andere Linux-Distributionen/BSD/MacOSX übertragbar. Für dir SSH-Verbindung muss das Paket openssh-server installiert sein. Ausserdem benötigen wir die sleepshell und puttygen.

DynDNS

Damit der Client den Host auch finden kann, sollte man sich eine DynDNS-Adresse zulegen. Dafür gibt es unterschiedliche Anbieter. Das ubuntuusers.de-Wiki hat einen Artikel zu dem Thema.

Port

Damit ein client zum Rechner des Hosts verbinden kann, muss die Firewall dies erlauben. Setzt man also einen NAT-Router ein, muss man einen Port auf den Rechner weiterleiten. In unserem Beispiel benutzen wir dafür Port 23900. Wie man Portweiterleitungen einrichtet sollte jeder selbst wissen ;-)

Remote-Benutzer einrichten

Damit der Client eine SSH-Verbindung mit unserem Rechner aufbauen kann, muss dafür ein extra Nutzer eingerichtet werden. Dieser bekommt einen passwortlosen SSH-Zugang, muss also entsprechend abgesichert werden.

wget http://www.mariovaldez.net/software/sleepshell/files/sleepshell_0.0.2.tar.gz
tar xzf sleepshell_0.0.2.tar.gz
make && sudo make install
sudo adduser --shell=/usr/local/bin/sleepshell remote-help
passwd -l remote-help
SSH-Key erstellen

Wer möchte kann die sleepshell.c vor dem kompilieren etwas anpassen, so dass für die Nutzer eine sinnvolle Nachricht wärend der SSH-Verbindung angezeigt wird. Z.B. "Verschlüsselte Verbindung aufgebaut. Fenster schliessen, um Verbindung zu trennen."

Als root sollte man jetzt noch dafür sorgen, dass das User-Verzeichnis /home/remote-help/ komplett leer ist und in einem .ssh-Verzeichnis ein noch zu erstellender public-key liegt. Das erledigen wir mit puttygen (Download s.o.), welches entweder in Windows ausgeführt werden muss, oder per wine auch unter Linux gestartet werden kann. Dort klickt man einfach auf Generate, um ein Schlüsselpaar zu generieren. Den privaten Schlüssel sollte man jetzt direkt wegspeichern (z.B. als id_rsa.ppk, brauchen wir später). Ein Passwort soll für den private key nicht vergeben werden. Das Fenster offen lassen, da wir den angezeigten öffentlichen Schlüssel sofort brauchen

sudo -i
cd /home/remote-help
rm -rf *
mkdir .ssh && cd .ssh
nano authorized_keys

Per Copy&Paste nun den Public-Key in das Terminal kopieren und mit STRG+X beenden und dann speichern. Jetzt müssen nich ein paar Rechte korrekt gesetzt werden.

cd ..
chmod -R 600 .ssh
chown -R remote-help: .ssh

Der Benutzer ist nun fertig eingerichtet. In der Nutzerverwaltung sollte man noch mal sicherstellen, dass der Benutzer in keinen Gruppen Mitglied ist. Als zusätzlich Maßnahme kann man nun noch den Benutzer sperren und nur jeweils dann aktivieren, wenn man auch gerade support geben will.

#Deaktivieren
usermod -e 1
#Aktivieren
usermod -e 9999

Der Host ist nun vollständig vorbereitet und abgesichert.

Client-Vorbereitung

VNC konfigurieren

Da es sich um einen Windows-client handelt, ist es vielleicht nicht schlecht, die folgenden Schritte unter Windows auszuführen. Linux und wine gehen aber auch. Von der UltraVNC Downloadseite brauchen wir die .zip-Datei welche das vollständige UltraVNC enthält. Aktuell ist das win32 bins 1.0.8.2 Full. Außerdem brauchen wir von der 7-Zip Downloadseite das Paket 7z Library, SFXs for installers, Plugin for FAR Manager. Zum Entpacken dieses Paketes braucht man noch 7-Zip selbst. Für die SSH-Verbindung brauchen wir plink von der PuTTY Downloadseite.

Am Besten legt man sich jetzt ein Verzeichnis an, in welches die Dateien kommen, die unser client braucht:

  • id_rsa.ppk – der private SSH-Schlüssel, den wir oben erstellt haben
  • plink.exe – Kommandozeilen-SSH-client
  • winvnc.exe – Server aus dem UltraVNC bin Paket
  • SCHook.dll – Bibliothek aus der UltraVNC bin Paket
  • ultravnc.ini – wird beim ersten Start des UltraVNC-Servers erstellt (siehe unten)
  • connect.cmd – Batch-Datei, welche die Verbindung aufbaut und den Server startet

UltraVNC muss man mind. 1x starten, damit eine Konfigurationsdatei erstellt wird. Man sollte ein Passwort vergeben (welches man sich natürlich merken muss), den Port fest auf 5900 (z.B.) stellen, loopback-Verbindungen erlauben und den JavaViever deaktivieren. Wenn man OK drückt wird die Konfiguration erstellt und der Server läft in Hintergrund (mit Icon im Tray). Den sollte man jetzt natürlich wieder beenden.

Die connect.cmd sollte folgenden Inhalt haben:

start winvnc.exe
plink -i id_rsa.ppk -C -R 23900:localhost:5900 remote-help@mein.dyndns.org

Wobei mein.dyndns.org die DynDNS-Adresse des Hosts ist, welche auf dessen IP verweist. 23900 ist der Port welcher auf dem Router des Hosts freigeschaltet und auf den Hostrechner weitergeleitet werden muss. 5900 ist der Port unter welchem der VNC-Server auf dem Client läuft.

1-Click-Client

Jetzt muss das ganze nur noch in eine selbstausführende Datei gepackt werden. Dafür legt man am Besten ein zweites Verzeichnis an, welches folgende Dateien enthalten soll:

  • 7zSD.sfx – sfx-header aus dem oben genannten 7-Zip Paket
  • client.7z – alle 6 Dateien aus dem vorigen Verzeichnis mit 7-Zip auf höchster Kompressionsstufe gepackt
  • config.txt – eine UTF-8 kodierte Datei, welche dem sfx-header sagt, was er zu tun hat

Die config.txt sollte folgenden Inhalt haben:

;!@Install@!UTF-8! 
;Title="" 
;BeginPrompt="" 
RunProgram="connect.cmd" 
;!@InstallEnd@!

Jetzt müssen die drei Dateien noch zu einer .exe-Datei zusammengefügt werden. Das geht folgendermaßen:

#Windows
copy /b 7zSD.sfx + config.txt + client.7z hilfe.exe
#Linux
cat 7zSD.sfx config.txt client.7z > hilfe.exe

Fertig

Der client ist jetzt fertig und kann so an die Hilfesuchenden verteilt werden. Wenn nun jemand Hilfe braucht, muss vorher natürlich der remote-help Benutzer, wie am Anfang des Artikels erklärt, aktiviert werden. Ist die Verbindung von Seiten des clients aufgebaut, startet man als Host irgendeinen VNC-client und verbindet mit localhost:23900.

Was, wenn ich nicht an dem Support-Rechner bin? Was wenn der Support-Rechner auch nicht erreichbar ist (wg. Firewall)?

Man kann selbstverständlich über SSH den Port 23900 auf dem Host-Rechner, auf jeden beliebigen anderen Rechner weiterleiten. Man hat dann einen VPN-Tunnel zwischen Host und Client und einen weiteren zwischen Host und dem Rechner an dem man gerade sitzt. Die Verbindung läuft quasi über Eck. Das geht z.B. so:

ssh -C -L 23900:localhost:23900 meinuser@mein.dyndns.org

Auf diese Art und Weise kann man übrigens auch das Problem umgehen, welches auftritt, wenn der Hilfegebende hinter einer Firewall sitzt, die er nicht beeinflussen kann. Der Host-Rechner kann dann bspw. ein Webserver sein. Der Hilfesuchende baut dann wine Verbindung zum Webserver mit dem remote-help user auf und leitet seinen Port 5900 an den Webserver (Port 23900) weiter. Dieser muss dann natuerlich entspr. konfiguriert sein, dass Port 23900 nur lokal zugreifbar ist. Der Hilfegebende baut nun ebenfalls eine Verbindung zum Webserver auf und leitet den Port 23900 des Webservers auf einen lokalen Port weiter. Zu diesem baut der dann eine Verbindung auf.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.