SSH + VNC = sichere + Fernwartung

Wie man merkt, steht dieses Wochenende ganz im Zeichen der Informatik-Blogartikel 😀 . Keine Sorge, es wird auch wieder andere Zeiten geben, aber zur Zeit steht der Homeserver halt hoch im Kurs 😉 . Auch wenn jetzt alle Linux-Fanboys wieder anfangen zu meckern: Der Server läuft unter Windows (XP Pro SP3).

Linuxer werden damit wahrscheinlich kein Problem haben, aber unter Windows ist die Wartung eines Servers ohne grafische Oberfläche ziemlich schwierig, da sich einige Serveranwendungen garnicht über die Kommandozeile administrieren lassen. Eine Lösung musste her!

Mein erster Gedanke war, von außen über VPN einen Tunnels lokale Netzwerk herzustellen und dann im Netzwerk über die Windows-eigene Remotedesktopverbindung auf die grafische Oberfläche zuzugreifen. Das Einrichten von Windows als VPN-Server war überhaupt kein Problem - sowohl die Serverfunktion, als auch die Clientfunktion sind direkt im Betriebssystem enthalten. Allerdings... über den Router wollte das ganze dann nicht mehr funktionieren... trotz etlicher freigegebener Ports 🙁 .

Zum Glück eilte mir mein Freund @Baschdii (aka. @SBejga) vom rosa Riesen zur Hilfe und erklärte mir, dass man auch über SSH-Verbindung einen Tunnel herstellen kann. Das ist ganz praktisch, denn SSH lief bei mir ja bereits - ich musste in der Konfiguration des Servers (freeSSHd) nur noch die richtige Einstellung finden:

freeSSHd Tunneling

Danach habe ich überlegt, welches Remote-Desktop-Programm ich am besten verwende. Als Protokoll stand VNC relativ schnell fest - doch welche Implementation davon? Es gibt so viele... Nach einigen herben Enttäuschungen (ultraVNC stach dabei als besonders schreckliches Beispiel heraus) habe ich mich dann für realVNC entschieden. Selbst die äußerst eingeschränkte kostenlose Version reicht für meine Zwecke vollkommen aus 😀 ! Im Vergleich zu einigen Kontrahenten sind sowohl der Server, als auch der Client, ziemlich einfach zu konfigurieren. Um den Server nach außen hin abzusichern, bedarf es einer besonderen Einstellung:

Only accept connections from the local machine


Mit dieser Installation sind die Änderungen am Server bereits abgeschlossen. Nun ist noch der Client an der Reihe. Dieser muss mit 2 Programmen ausgerüstet werden, die man dank der Größe (ca. 6MB) eigentlich immer bei sich haben kann. 🙂

Zuerst einmal benötigen wir ein Programm, mit dem wir den SSH-Tunnel zum Server aufbauen können. Für viele dürfte Putty als SSH-Client ein Begriff sein. Baschdii hat mich dagegen auf das Programm Tunnelier aufmerksam gemacht: Und in der Tat! Das Einrichten des Tunnels war ein Klacks 😀 ! Zuerst einmal trägt man im Login-Tab die SSH-Daten (Host, Port, Benutzername) ein:

Tunnelier: Login-Tab


Danach geht man auf den C2S-Tab und stellt dort den eigentlichen Tunnel ein. Die Konfiguration könnt ihr dem Screenshot entnehmen (Listen Interface = 127.0.0.1, List. Port = 5900, Destination Host = 127.0.0.1, Dest Port = 5900):

Tunnelier: C2S-Tab


Jetzt muss man über Tunnelier nur noch die SSH-Verbindung zum Server herstellen lassen und den realVNC-Client starten. Diesen kann man bereits normal benutzen - mit einer Ausnahme: Als Host muss die Adresse 127.0.0.1 angegeben werden!

realVNC-Client


Nach dem Klick auf "OK" passiert nun folgendes: Der "Viewer" verbindet sich mit dem lokalen Rechner und der Portnummer 5900. Dieser Port wurde von Tunnelier geöffnet und alle Daten, die der Viewer schickt, landen beim SSH-Client. Dieser schickt sie weiter an den SSH-Server, der wiederum bei sich lokal eine Verbindung zum Port 5900 aufgebaut hat - der Port, auf dem der echte realVNC-Server lauscht.
Auf diese Weise werden alle Daten, die die beiden VNC-Anwendungen austauschen über die SSH-Verbindung geleitet. Damit sollte ein Mitlesen oder gar Manipulieren der Daten durch Dritte effektiv verhindert werden 😀 !
Fernwartende Grüße, Kenny

3 Kommentare » Schreibe einen Kommentar

  1. Real VNC ist eine gute Idee, ultraVNC macht unter Windows 7 noch mehr Probleme. Was ich allerdings nicht verstehe, warum die Remotedesktopverbindung nicht funktioniert. In der Firma verwenden wir das für Fernawartung. Kenne allerdings die Konfiguration nicht. Muss das die Firewall unterstützen?

    • Das Problem ist in erster Linie nicht die Fernwartung, sondern die VPN-Verbindung. Die Remotedesktopverbindung wollte ich nicht ohne zusätzliche Verschlüsselung einsetzen. Ich hatte es jedoch nicht hinbekommen, die VPN-Verbindung über meinen Router weiterzuleiten - evtl. unterstützt er einfach kein VPN Path Through. Theoretisch könnte man den SSH-Tunnel dazu verwenden, nun die Remotedesktopverbindung durchzuleiten. Dann müsste man auf Client-Seite jedoch jedesmal die verschiedenen Ports angeben, die dafür benötigt werden.

  2. Pingback: Linktipps: Fernwartung, Google, Chrome, Ubuntu, Streaming

Schreibe einen Kommentar

Um Ihnen beim weiteren Kommentieren auf dieser Webseite die erneute Eingabe Ihrer Daten zu ersparen, wird beim Absenden Ihres Kommentars ein Cookie an Ihren Browser gesendet und von diesem gespeichert. Mit dem Absenden eines Kommentars auf dieser Webseite stimmen Sie der Speicherung und Übertragung dieses Cookies explizit zu.

Pflichtfelder sind mit * markiert.