Für die Fernwartung eines PCs oder das Erklären von Bedienungsschritten über große Entfernungen hinweg, gibt es sogenannte VNC-Software (Virtual Network Computing). Diese ist in der Lage den Bildschirm eines entfernten Rechners (Servers) auf dem heimischen Rechner (Client) anzuzeigen und Tastatur und Mausbewegungen zu übertragen. Dadurch ist es möglich an einem entfernten Rechner zu arbeiten, als säße man direkt davor. VNC ist dabei plattformunabhängig und kann daher sowohl für Verbindungen von Linux zu Windows als auch umgekehrt verwendet werden. Unter Linux wie auch Windows gibt es dafür die OpenSource Software tightvnc, sowie speziell unter kde die Programme krfb (Arbeitsfläche freigeben) und krdc (Verbindung zu Fremdrechner). Widmen wir uns zuerst den KDE-Programmen, welche eigentlich selbsterkärend sind, da sie eine grafische Oberfläche haben. Doch vorab noch ein Hinweis:

VNC-Verbindungen sind grundsätzlich unverschlüsselt! Sämtliche Passwörter werden im Klartext übertragen und sind daher abgreifbar. Möchte man eine VNC-Verbindung über das Internet herstellen, ist eine Verschlüsselung via eines SSH-Tunnels absolut ratsam!

krfb und krdc - VNC-Verbindungen via KDE

Beide Programme findet man im K-Menü unter Internet. Mittels krfb startet man den VNC-Server der die Desktop-Freigabe ermöglicht. Dabei hat man zwei Möglichkeiten. Entweder kann man mittels Persönlich einladen... eine Einladung erstellen, welche ein automatisches Paßwort generiert oder man klickt auf Einrichten... und erstellt eine dauerhafte Freigabe der Arbeitsfläche. Bei einer dauerhaften Freigabe muß man das Häckchen unter Verbindungen ohne Einladungen erlauben setzen und kann anschließend noch Häkchen vergeben, ob der Dienst im Netzwerk sichtbar sein soll, ob man noch zusätzlich den Zugriff bestätigen will und ob der entfernte Client die Arbeitsfläche überhaupt steuern darf. Läßt man bei letzterem das Häckchen weg, kann der Client lediglich die Arbeitsfläche sehen und somit beobachten, aber keinerlei Mausbewegung initiieren (View-Only Modus). Wichtig ist, daß man ein Paßwort vergibt, denn macht man das nicht, öffnet man seinen Rechner für jedermann im Internet. In dem Sinne ist eine gewisse Vorsicht geboten wenn man einen VNC-Server abstartet! Um sich nun mit dem entfernten Rechner zu verbinden, startet man krdc ab, gibt die I.P. oder bei vorhandener Namensauflösung den Hostnamen des Rechners an gefolgt von der Display-Nummer, z.B. 192.168.1.20:0. Nach einer Paßwortabfrage öffnet sich ein Fenster und man sieht den entfernten Desktop. Übrigens kann man sich dank der Plattformunabhängigkeit von VNC mittels der Windows-Version von tightvnc auf einen krfb-Server ohne Probleme einloggen und umgekehrt mittels krdc auf einen Windows-tightvnc-Server ebenfalls.

tightvnc

Unter der Seite http://www.tightvnc.com kann man sich die Windows-Version von tightvnc herunterladen. Dabei hat man die Qual der Wahl zwischen einer älteren Version 1.3.10, die die neueren Windows-Versionen wie Vista oder 7 nicht vollständig unterstützt aber dafür als Executables also ausführbare Dateien ohne Installation heruntergeladen werden kann oder der neuen Version 2.5.1 mit voller Unterstützung für alle Windows-Varianten die jedoch eine Installation benötigt. Unter Debian findet man das Programm in den Paketlisten und ein simples
# apt-get install xtightvncviewer tightvncserver
installiert die Programme. Leider verhalten sich die Programme unter Windows und Linux etwas unterschiedlich. Während der tightvnc-Server auf der Windows-Seite sich genau wie krfb verhält, also den Desktop unter der Display-Nummer :0 für einen Client shared und somit Maus- und Tastaturbewegungen auf beiden Seiten sichtbar sind, wird mittels tightvncserver unter Debian ein eigener X-Server mit der Display-Nummer :1 gestartet. Um das besser verstehen zu können ein Beispiel:
Startet man unter Windows den vncserver mittels der Datei winvnc.exe, wird der momentane Windows-Desktop mit der Display-Nummer :0 über das Netzwerk freigegeben. Stellt man nun eine Verbindung mittels vncviewer her (unter Debian xvncviewer), sieht man nicht nur den Windows-Desktop, sondern auch die Mausbewegungen auf beiden Seiten. Unter Debian läuft ja in der Regel schon ein X-Server mit der Display-Nummer :0. Startet man hier nun den vncserver wird ein eigener X-Server mit der Nummer :1 gestartet, anstatt den momentanen Desktop mit der Nummer :0 zu sharen. Greift man nun von Windows mittels dem tightvncviewer auf diesen X-Server zu, sieht der User am Debian-Rechner nichts von den Aktionen des Windows-Nutzers, da er ja das Display :0 vor sich hat, während der Windows-Nutzer sozusagen an seinem eigenem Display mit der Nummer :1 arbeitet. Möchte man das gleiche Verhalten wie unter Windows, muß man sich des Programms x11vnc bedienen. Selbiges stellt den momentan laufenden X-Server mit der Nummer :0 für Zugriffe aus dem Netzwerk bereit. Daher meine Empfehlung: Ein zusätzliches
# apt-get install x11vnc

Unter Windows ist tightvnc wieder selbsterkärend, bzw. ähnlich aufgebaut wie die KDE-Programme. Unter Linux sind es in erster Linie Konsolenprogramme und so muß man sich zumindest was tightvncserver für den ersten Start anbelangt der Konsole bedienen, um die Programme abzustarten. tightvncserver verlangt nach dem ersten Start ein wenig Konfiguration und weil eine grafische Oberfläche fehlt, kann man selbige nur auf der Konsole durchführen. Nach dem Start mittels
# tightvncserver
wird man nach dem Paßwort für den Server gefragt und ob ein Paßwort für einen view-only Modus verwendet werden soll. Hat man beides eingegeben, wird im Heimatverzeichnis das versteckte Verzeichnis .vnc angelegt, in welchem die Konfiguration und die Log-Dateien gespeichert werden. Gleichzeitig wird der X-Server mit der Display-Nummer :1 abgestartet, was man unter KDE an einem ablaufendem Startsound bemerkt. Möchte man den Server wieder beenden, ruft man entweder den Befehl
# tightvncserver -kill :1
auf oder sucht mittels ps -A | grep vnc den laufenden Prozess und beendet ihn mit kill Signalnummer. Leider gibt es kein Icon im Tray, was einem den laufenden Prozess anzeigt. Für zukünftige Starts von tightvncserver kann man den Befehl gleich im Befehl ausführen... Dialog eingeben, muß aber zum beenden sowieso wieder die Konsole öffnen. Möchte man die Auflösung des X-Servers einstellen, kann man das als Option mitgeben, z.B.
# vncserver :1 -geometry 1280x1024 -depth 16 -pixelformat rgb565
Dabei steht :1 für die Display-Nummer, -geometry für die verwendete Auflösung, -depth für die verwendete Farbtiefe und -pixelformat für das Farbformat zur Pixelanzeige.
xtightvncviewer kann man gleich entweder von der Konsole oder per Befehl ausführen-Dialog abstarten. Es folgen zwei kleine Fenster in welche man den entfernten Server (z.B. buero:0 oder 192.168.2.5:1) und das verwendete Paßwort eingeben kann.

x11vnc

Wie bereits erwähnt, wird mittels tightvncserver ein eigener X-Server abgestartet. Möchte man das momentane Display unter Linux im Netz freigeben, muß man sich des Programms x11vnc bedienen. Dabei gibt ein schlichtes
# x11vnc
auf der Konsole gleich mal eine fette Warnmeldung aus, da kein Paßwort angegeben wurde. Wir erinnern uns: Damit laden wir sämtliche Internet-User ein ein wenig mit unserer Maus zu spielen...
Möchte man ein Paßwort vergeben, kann man das mittels
# x11vnc -storepasswd /Speicherort/der/Paßwortdatei
machen. Läßt man den Speicherort der Datei weg, wird die Paßwortdatei automatisch unter .vnc/passwd angelegt. Diesselbe Datei benutzt auch tightvncserver, also hat man schon beim Einrichten von tightvncserver ein Paßwort vergeben, erübrigt sich dieser Schritt. Wichtig ist nun die Angabe der Paßwort-Datei beim Abstarten von x11vnc:
# x11vnc -rfbauth ~/.vnc/passwd -display :0
Und somit wird genau wie unter krfb der momentane Desktop zur gemeinsamen Nutzung geshared. Die zusätzliche display-Angabe sagt, daß das Display mit der Nummer :0 geshared werden soll. Ohne diese Angabe braucht x11vnc ein wenig länger zum Abstarten, da es erst prüft welches Display läuft. Nach jedem Schließen der Sitzung beendet sich auch x11vnc und man muß es für eine erneute Sitzung wieder neu abstarten. Möchte man das nicht, hilft die Option -forever:
# x11vnc -forever -rfbauth ~/.vnc/passwd -display :0
Leider kam es bei mir des öfteren vor, daß wenn ich mich mit Krdc als Client mit X11vnc verbunden habe, daß die Verbindung abgestürzt ist und beendet wurde. Wem das auch passiert, dem empfehle ich als Alternative zu Krdc den xtightvncviewer. Mit Eingabe des Namens auf der Konsole startet man das Programm ab. Das Programm selbst ist sehr schlicht. Man gibt lediglich den Server und das Paßwort an und schon läuft die Sitzung. Etwas mehr Optionen kann man mittels der F8 Taste einblenden.

Verschlüsselte VNC-Verbindung mittels ssh und x11vnc

Um eine verschlüsselte und damit gesicherte Verbindung zu einem entfernten Desktop aufzubauen, kann man das VNC Protokoll über ssh tunneln, d.h. man baut eine ssh-Verbindung auf über die der Port 5900 und damit die VNC Verbindung geleitet wird. Das Schöne daran, man muß sich nicht mal vorher auf dem entfernten Rechner mittels ssh einloggen und den VNC-Server abstarten, denn das geht in einem Befehl. Dazu öffnet man zwei Konsolen und gibt auf der Ersten ein:
# ssh -t -L 5900:localhost:5900 benutzer@entfernter.rechner 'x11vnc -display :0 -rfbauth ~/.vnc/passwd -listen 127.0.0.1'
Damit wird eine ssh-Verbindung aufgebaut, die den Port 5900 tunnelt und das Programm x11vnc auf dem entfernten Rechner ausführt. Wird die VNC-Verbindung beendet und damit x11vnc, wird man automatisch wieder ausgeloggt am fremden Rechner. Mittels der zweiten Konsole und dem Programm vncviewer (tightvncviewer) kann man sich verbinden:
# vncviewer -encodings "copyrect tight zrle hextile" localhost:0
Bei schnellen, lokalen Netzwerken kann man die encodings-Option auch weglassen. Sie dient lediglich der Optimierung der Geschwindigkeit bei langsamen Internet-Verbindungen.

Verschlüsselte VNC-Verbindung mittels Jump Desktop auf Android und x11vnc

Wer sich mittels seines Smartphones auf seinem heimischen Rechner per VNC verbinden will, kann das Programm Jump Desktop für circa 10 Euro im Google Play Store erwerben. Natürlich gibt es auch kostenfreie Alternativen, jedoch habe ich keine kostenfreie gefunden die eine Verschlüsselung über ssh anbietet, was Jump Desktop von Haus aus mitbringt und damit gerade bei einem solch unsicheren Medium wie dem Smartphone wesentlich sicherer ist als die kostenlosen Alternativen.

Bevor man sich mittels Jump Desktop verbinden kann, muß natürlich auf dem entfernten Rechner x11vnc laufen. Entweder hat man das Programm schon vorher abgestartet oder man kann es mittels eines ssh-Clients mit dem man sich auf der entfernten Maschine einloggt:
# x11vnc -display :0 -rfbauth ~/.vnc/passwd -listen 127.0.0.1
Dabei sorgt die Option -listen 127.0.0.1, daß x11vnc nur auf Verbindungen vom eigenen Rechner lauscht und somit ist es nicht möglich, daß sich ein Fremder aus dem Internet einloggen kann.

Anschließend startet man Jump Desktop ab und konfiguriert es wie folgt:

VNC-Verbindung
1. Manuelle Konfiguration auswählen.
2. Ein neue Verbindung mittels des Plus-Zeichens erstellen.
3. Als Connection Type gibt man VNC an.
4. Als Host-Address 127.0.0.1 eintragen.
5. Der Port ist 5900.
6. Die Authentication Method: VNC-Password.

SSH-Tunnel
Ein Fingertip auf den SSH-Tunnel öffnet den Einstellungs-Dialog. Auch hier muß man zunächst eine neue Verbindung anlegen, in welche man den Anmeldenamen, den Hostnamen vom entfernten Rechner (normalerweise eine DynDNS-Adresse), den Port (Standard ist 22) und die Authentifizierung -ob Schlüssel oder Passwort- für SSH einträgt.

Hat man alles bestätigt, kann man sich verbinden. Dazu baut Jump Desktop zuerst eine SSH-Verbindung auf und fragt nach dem SSH-Passwort. Nach Eingabe folgt die Abfrage für das VNC-Passwort und schon ist man über einen gesicherten SSH-Tunnel verbunden.

x11vnc mit kdm login

Um mittels x11vnc den Zugriff auf einen Login Screen zu ermöglichen, wie z.B. den Login Screen des Display Managers kdm, braucht man das Xauthority File, welches das "MIT-MAGIC-COOKIE" enthält. Um herauszufinden welches File man benötigt, kann man sich folgendem Befehl bedienen:
# ps wwaux | grep auth
root 1116 0.1 0.9 186064 75524 tty7 Ss+ 04:42 0:04 /usr/bin/X :0 vt7 -br -nolisten tcp -auth /var/run/xauth/A:0-D2NXbc
Wie man sieht, liegt unser File unter /var/run/xauth/. Leider gibt es hier ein kleines Zugriffs-Problem, da das File nur root zugänglich ist. Daher muß man x11vnc mit root-Rechten starten. Vorher sollte man nicht vergessen, ein Passwort-File für root zu erstellen. Und es gibt noch einen weiteren Stolperstein: Unter KDE mit kdm ändert sich die Bezeichnung des Files nach einem Neustart. Wer jedoch nicht ständig nach der Bezeichnung suchen und seinen Befehl anpassen will, kann der -auth Option auch "guess" mitgeben. Dadurch versucht x11vnc zu raten, welches File gemeint ist.
# x11vnc -auth guess -display :0 -rfbauth ~/.vnc/passwd -listen localhost