Jerret.de

So ziemlich jeder Systemadministrator kennt VNC (Virtuel Network Computing). Über VNC lassen sich entfernte Rechner über das Netzwerk oder das Internet fernadministrieren. Dabei wird die laufende Desktopsitzung des zu administrierenden Rechners über das Netz an den Systemadministrator übermittelt. Grundvoraussetzung dabei ist natürlich ein sogenannter VNC-Server, der die Verbindung zur Verfügung stellt und ein sogenannter VNC-Client, der die Verbindung zum Server aufbaut. Der VNC-Server läuft dabei auf dem Rechner, der zu administrieren ist.

Am häufigsten wird VNC sicherlich in großen Netzwerken verwendet. Das erspart einem Systemadminstrator unter Umständen viel Zeit. VNC ist dabei für viele Betriebssysteme erhältlich und erfreut sich einer zunehmenden Beliebtheit.

Innerhalb eines gesicherten Netzwerkes ist die Nutzung von VNC auch “unbedenklich”. Was aber, wenn ein Rechner außerhalb eines gesicherten Netzwerkes administriert werden muss? Da die Datenübertragung einer VNC-Session unverschlüsselt erfolgt, stellt sich die Frage, wie z.B. über das Internet eine VNC-Session abzusichern ist?

Diese Fragestellungen gilt es im Folgenden zu klären.

Zielsetzung

Mit Mac OS X oder Linux eine VNC-Session zu einem über das Internet erreichbaren Linuxhost durch einen SSH-Tunnel

SSH (Secure Shell)

Was SSH genau ist und wie SSH funktioniert, möchte ich hier nicht weiter erläutern, sondern verweise gerne auf Wikipedia. Nur so viel: Daten, die über SSH transportiert werden, sind verschlüsselt und können nicht ohne Weiteres ausgelesen werden.

Administratoren nutzen SSH, um sich z.B. auf entfernten Rechnern sicher anzumelden. Die Kommunikation findet dann aber zumeist auf Kommandozeilenebene statt.

VNC-Server

Der VNC-Server auf einem Linuxhost ist relativ einfach zu bedienen. Fast jede Linux Distribution hat standardmäßig einen VNC-Server dabei. Falls nicht, ist es aber meist nicht schwer, den VNC-Server zu installieren. Ist der VNC-Server installiert, reicht ein einfacher Befehl “vncserver” auf der Kommandozeile, um den VNC-Server zu starten. Ich bevorzuge jedoch folgenden Befehl:

• vncserver -geometry 1280×1024

Damit erhalte ich die Auflösung von 1280×1024 Bildpunkten bei der VNC-Session.

Auf meinem Testsystem quittiert mir der VNC-Server nach dem Starten also die neue Desktop-Session wie folgt:

• New ‘X’ desktop is meintesthost:1

Die “1″ hinter dem Hostnamen zeigt, dass hier die erste Desktop-Session initialisiert wurde. Jede weitere würde die Zahl je um eins erhöhen (nur so als Randinfo…).

Aufbau des SSH-Tunnels

Der Aufbau einer SSH-Verbindung zu einem entfernten Linuxhost ist einfach. Hier gibt es SSH-Clients oder man bedient sich ganz einfach “old school” der Konsole. Ich mache es kurz und schmerzlos – den SSH-Tunnel initialisiert man mit folgendem Befehl:

• ssh -N -L 5900:localhost:5901 user@linuxhost.de

Dabei wird definiert, welcher lokale VNC-Port zum externen VNC-Port weitergeleitet wird. Wird der Tunnel über die Konsole “gegraben”, so bleibt das Termial bzw. die Konsole für die Dauer der VNC-Session blockiert.

VNC-Session

Um nun die VNC-Session vom entfernten Host über den SSH-Tunnel zu bekommen, muss lediglich per VNC-Client eine Verbindung zum Tunnel aufgebaut werden, nicht jedoch zum entfernten Host. Ein herkömmlicher freier VNC-Viewer als Client ist vollkommen ausreichend, um die Verbindung herzustellen.

Dabei ist lediglich darauf zu achten, dass als VNC-Server nicht der entfernte Host anzugeben ist, sondern der eigene Rechner, also in der Regel “localhost”. Jetzt noch den richtigen Port angeben und schon steht die VNC-Session über dem SSH-Tunnel.

Das sollte dann so aussehen: localhost:5900

Artikelupdate ->Windows

Ich habe heute einen interessanten HowTo gefunden, welcher das Gleiche für Windows-Nutzer beschreibt.

• http://fli4l.anadex.de/vnc_ssh_howto.html

… Wozu soll genau das gut sein? Eine frage, die ich mir auch gestellt habe. Jetzt, da ich auch eigene Unix-Server in Düsseldorf und Nürnberg stehen habe, kann ich diese Frage genau beantworten.

Genau wie viele andere, bin ich voll berufstätig und habe eine zweite Einnahmequelle. Das Betreiben von eigenen Servern. Im Grunde nichts außergewöhnliches. Spannend wird es jedoch, wenn dadurch Abhängigkeiten zu Kunden bestehen. Dann wird es plötzlich sehr wichtig, dass die Server auch laufen.

Alle diejenigen, die sich in einer ähnlichen Situation befinden, werden ihren Server in der Regel fernadministrieren. Die wohl gängigste Methode, dieses zu tun, ist wohl SSH (Secure Shell).

Die standardmäßige Kommunikation zwischen Client und Server findet über Port 22 statt.

Um nun auf die Ausgangsfrage zurückzukommen; Aber warum sollte man ausgerechnet den Port 443 für die SSH-Verbindung wählen?

Viele Arbeitgeber gewähren Ihren Mitarbeitern Zugang zum Internet. Wenn ein Zugang zum Internet besteht, ist es natürlich für die Firmen sehr wichtig größt mögliche Sicherheit für das eigene Unternehmen zu gewährleisten. Dabei ist es unabdingbar eine sichere Firewall aufzubauen. In der Regel wird dies über die Konfiguration von Routern und Proxies implementiert. Dabei kommt es nicht selten vor, dass die Kommunikation über Port 22 (SSH) abgeblockt wird.

Da das Internet an sich ja noch erreichbar sein soll, sind meist Port 80 und Port 443 nicht geblockt. Über Port 80 läuft in der Regel der normale HTTP Datenverkehr und über Port 443 der verschlüsselte Datenverkehr HTTPS. Diesen Umstand kann man sich als Serveradministrator zu nutze machen.

In der Konfiguration für den SSH-Server (z.B. /etc/ssh/sshd_config) richtet man einfach den Port 443 ein, auf den der SSH-Deamon zusätzlich lauschen soll. Nach einem Neustart des SSH-Servers ist es nun möglich sich über den Standardport 22 und den Port 443 zu verbinden.

Jetzt kann man sich vom Arbeitsplatz ohne Probleme auf seinem Server anmelden. Man mus nur noch die IP des Poxies kennen, wissen über welchen Port des Proxies der Internetdatenverkehr läuft und schon kann man einen SSH-Client (z.B. Putty) so konfigurieren, dass die Verbindung zum SSH-Server aufgebaut werden kann.

Und warum lass ich den SSH-Server nicht auf Port 80 lauschen? Diese Frage ist leicht zu klären. Viele Serverbesitzer betreiben einen Webserver. Ein Webserver lauscht in der Regel auf Port 80. Hier wird es zu konflikten kommen. Selbst wenn kein Webserver im Einsatz ist, sollte man nicht Port 80 benutzen. Der Netzwerkadministrator einer Firma merkt sofort, wenn versucht wird über Port 80 verschlüsselte Daten zu übertragen. Das wird Ärger geben.

Datenverkehr über Port 443 ist eh verschlüsselt. Der Netzwerkadministrator kann zwar auf Paketebene Datenverkehr der jeweiligen Protokolle unterscheiden, dieses wird aber praktisch nicht gemacht. Zu viel Aufwand.

Beispiel

Ausgangssituation

• Arbeitgeber lässt Internet über HTTP und HTTPS zu.
• Proxyserver hat die IP 10.10.10.10 und benutzt Port 9090

Serverseitig

• SSH-Server auf 123.456.789.111 lauscht auf Port 22 und 443

Clientseitig (an Beispiel Putty)

Mit dieser Clientseitigen Konfiguration ist es nun Möglich eine SSH-Verbindung zum Server aufzunehmen.

Viel Spaß…