Neue Funktionen für mehr Sicherheit und Bedienkomfort

Neu ist die Möglichkeit, den Sperrbildschirm mit einem Passwort zu schützen. Damit lassen sich laufende Sitzungen besser absichern. Ebenfalls neu ist eine integrierte Screenshot-Funktion, die es erlaubt, während einer Verbindung Bildschirmfotos zu erstellen. Man erreicht sie über das Menü im Remotescreen und dann das Blitz-Icon und Screenshot aufnehmen. Man hat dann die Wahl, den Screenshot abzuspeichern oder in die Zwischenablage zu kopieren.

Die Unterstützung von WebSockets wurde auf allen Plattformen eingeführt, was unter bestimmten Netzwerkkonfigurationen stabilere Verbindungen ermöglicht. Zusätzlich lässt sich die Trackpad-Geschwindigkeit nun individuell anpassen – eine sinnvolle Ergänzung insbesondere auf Notebooks.

Technische Änderungen unter der Haube

Mit der neuen Version entfällt die Abhängigkeit vom System-Proxy im HTTP-Client. Zudem nutzt RustDesk beim Einsatz von Socks5-Proxys jetzt ausschließlich TCP, da die Konfiguration von UDP häufig zu Problemen geführt hatte.

Im Tray-Menü wurde der Eintrag Exit durch Stop service beziehungsweise in der deutschsprachigen Version Vermittlungsdienst stoppen ersetzt, um klarer zu kommunizieren, dass damit der Hintergrunddienst und damit die Möglichkeit, sich auf dem System einzuloggen, beendet wird, nicht nur die Oberfläche. Somit kann man das Programm weiter nutzen, um sich auf anderen Rechnern einzuloggen.

Fehlerbehebungen

RustDesk 1.4.0 korrigiert eine Reihe bekannter Fehler:

• Probleme bei der Verwendung von HTTP-Proxys
• Fehler bei der automatischen Erkennung im LAN
• defektes Scrollverhalten mit dem Mausrad
• fehlerhafte Anzeige von Remote-Tabs
• falsche Statusanzeige bei aktiviertem 2FA
• Verbindungsprobleme bei RDP-Sitzungen
• Startprobleme beim Ausführen über sudo
• ein macOS-spezifischer Bug beim Einsatz der virtuellen F11-Taste

Verfügbarkeit

RustDesk 1.4.0 steht auf GitHub für Linux, Windows, macOS, Android und iOS zum Download bereit. Unterstützt werden verschiedene Architekturen wie x86-64, AArch64 und ARMv7. Verbindungen von und zu Rechnern, die mit Wayland laufen, haben ohne Probleme funktioniert. Inzwischen gibt es für mich kaum mehr Hindernisse beim Einsatz von Wayland.

In Arch Linux ist derzeit noch Version 1.3.9 in den offiziellen Repositories enthalten. Der Umstieg auf RustDesk 1.4.0 erfordert hier aktuell noch manuelle Schritte oder Geduld bis zur Paketaktualisierung. Als Alternative kann man sich das AppImage schnappen. Runterladen, ausführbar machen und starten. Hat auf meinem System gut funktioniert.

Ebenfalls neu ist die Möglichkeit, die Kamera eines entfernten Systems einzusehen, was sich für Support-Szenarien als nützlich erweisen kann. Die Funktion ist allerdings ein wenig versteckt: Ihr müsst ins Kontextmenü der Verbindung gehen und dort die Option Kamera anzeigen auswählen. Über die Symbolleiste geht das nicht. Allerdings lassen sich Kamera und Remote-Desktop gleichzeitig nutzen.

Das ist neu in RustDesk 1.3.9

Gerade für private Anwender, die RustDesk zur Fernwartung von Familie und Freunden nutzen, ist die neue Kamera-Unterstützung besonders spannend. Damit könnt ihr nicht nur sehen, was auf dem entfernten Bildschirm passiert, sondern auch, was vor der Kamera des anderen Geräts geschieht. Das kann helfen, wenn ihr jemandem bei Hardware-Problemen oder anderen technischen Herausforderungen unter die Arme greifen wollt.

Gut funktioniert auch das Kopieren von Dateien von einem System auf das andere über die Zwischenablage. Hier kopiere ich beispielsweise eine Datei aus GNOME mit Wayland und Nautilus in ein Remote-System mit KDE Plasma und Dolphin als Dateimanager. Einfach mit Strg+C kopieren und dann mit Strg+V einfügen – ganz so, als würde man nur lokal auf seinem eigenen System arbeiten.

RustDesk unter Linux installieren

Wenn ihr RustDesk unter Linux nutzen wollt, habt ihr verschiedene Möglichkeiten:

• Arch Linux: Hier könnt ihr das Programm über das Arch User Repository (AUR) beziehen. Die Wahl liegt zwischen rustdesk-bin für eine schnelle Installation oder rustdesk, wenn ihr den Code selbst kompilieren und mehr Kontrolle über das Paket haben wollt.
• Andere Distributionen: Auf der Projektseite findet ihr vorgefertigte Pakete der aktuellen Version für viele gängige Distributionen, darunter .deb- und .rpm-Pakete für Debian, Ubuntu, Fedora und Co.

Die Open-Source-App RustDesk bleibt eine interessante Alternative zu kommerziellen Remote-Desktop-Lösungen. Der große Vorteil: Ihr könnt bei Bedarf einen eigenen Relay-Server betreiben und damit nicht nur schnellere Verbindungen ermöglichen, sondern auch volle Kontrolle über eure Daten behalten. Mit Version 1.3.9 kommen sinnvolle Neuerungen hinzu, die vor allem für private Nutzer hilfreich sein können. Probiert es aus!

In so einem Fall steht man mit Recht stumpfen Waffen da. Um weiter helfen zu können müsste man erstmal wieder die den Xserver oder die Paketverwaltung zum Laufen bekommen, doch damit sind Einsteiger üblicherweise überfordert — selbst wenn man sie telefonisch dazu anleitet. Die beste Option wäre ein Login über SSH, doch dazu müsste man den Openssh-Server installieren und eine Portweiterleitung vom Router zum Rechner einrichten. Mit einer defekten Paketverwaltung funktioniert auch dieses nicht, selbst wenn man die Hürde Portweiterleitung meistert.

Tmate, der Teamviewer für das Terminal

Als Lösung für dieses Dilemma bietet sich nun aber Tmate an. Das Programm basiert auf dem Terminalmultiplexer Tmux (ähnlich dem Kommando screen), allerdings hat Tmat eine Remote-SSH-Funktion integriert, die sich ähnlich wie Teamviewer durch ein NAT-Netzwerk oder eine Firewall hindurchtunnelt. Das Programm müsst ihr sowohl auf dem Zielrechner wie auch eurem System installieren. Man erhält es unter Arch aus dem AUR, für Ubuntu-User gibt es ein PPA. Alternativ gibt es auch Builds für FreeBSD, Gentoo oder MacOS X via Homebrew.

Tmate auf dem Rechner des Helfenden installieren

### Installation von Tmate unter Arch Linux
$ pacaur -S tmate
### Installation von Tmate unter Ubuntu
$ sudo add-apt-repository ppa:tmate.io/archive
$ sudo apt update
$ sudo apt install tmate

Sollte auf dem Zielrechner die Paketverwaltung nicht funktionieren, von daher die Installation weiterer Pakete nicht möglich sein oder es kommt eine andere Distribution wie beispielsweise Fedora oder Debian zum Einsatz, dann kommt man mit dem PPA natürlich auch nicht weiter. Für diesen Fall gibt es von den Tmate-Entwicklern „Static Builds“ für 32- und 64-Bit Systeme. Diese muss man lediglich in Form eines TAR-GZ-Archivs auf dem betroffenen Rechner herunterladen, entpacken und anschließend das tmate Binary aufrufen.

Tmate behelfsmäßig als statisches Binary laden

### Static Build von Tmate für 64-Bit Rechner herunterladen...
$ wget https://github.com/tmate-io/tmate/releases/download/2.2.1/tmate-2.2.1-static-linux-amd64.tar.gz
### Static Build von Tmate für 32-Bit Rechner herunterladen...
$ wget https://github.com/tmate-io/tmate/releases/download/2.2.1/tmate-2.2.1-static-linux-i386.tar.gz
### Tmate enpacken und starten (im Falle eines 64-Bit-Systems)
$ tar xzf tmate*
$ tmate-2.2.1-static-linux-amd64/tmate

Solltet ihr einem Einsteiger helfen wollen, dann würde ich empfehlen die Aktion ein wenig zu vereinfachen: Holt euch das Binary und packt es ein Unterverzeichnis in ein neues Archiv mit einem einfacheren Dateinamen. Legt dieses dann auf einem eigenen Webspace ab und kommuniziert dem Hilfesuchenden ein Wget-Kommando mit einer Kurz-URL (nutzt dafür einen URL Shortener eurer Wahl). Das erspart dem Hilfesuchenden viel Tipparbeit und verhindert Fehler. Im Beispiel belasse ich es jedoch bei den „original“ Dateinamen und Pfaden. Achtet darauf, dass es natürlich auch demnächst neue Versionen des Programms gibt.

Ist Tmate auf dem Patienten installiert, erhält der User eventuell beim ersten Aufruf des Programms die Meldung [tmate] Reconnecting... (SSH keys not found. Run 'ssh-keygen' to create keys and try again.) auf dem Schirm. Dies passiert, wenn auf dem Rechner bislang noch kein SSH-Server installiert war… was bei einem Linux-Einsteiger oft der Fall ist. Ubuntu installiert beispielsweise den OpenSSH nicht von Haus aus als Server. Andere Distributionen liefern diesen jedoch oft automatisch mit aus.

In Falle des Fehlers könnte man nun den SSH-Server nachinstallieren, allerdings muss das gar nicht sein. Es genügt das System anzuweisen einmalig die SSH-Schlüssel erstellen zu lassen. Weist daher den Hilfesuchenden an, Tmate mit der Eingabe von exit zu beenden und das Kommando ssh-keygen einzutippen — es braucht dazu auch keine Root-Rechte. Jede der anschließenden Fragen kann ganz simpel mit [Eingabe] ohne weitere Eingaben abgenickt werden. Am Ende landet der user wieder auf einer Eingabeaufforderung.

Nun könnt ihr die eigentliche Tmate-Sitzung starten: Beim Aufruf des Programms erscheint eine Zeile in der Art ssh sehr-sehr-lange-tmate-id@tmate-server unten in der Statuszeile des Anwendungsfensters — An dieser Stelle gilt es ein wenig Aufmerksam zu sein und die Adresse rechtzeitig zu sichern. Nach ein paar Sekunden verschwindet diese Zeile und man muss Tmate mit exit einmal beenden und wieder neu aufrufen, um eine neue ID zu erstellen. hat es geklappt, muss euch der Hilfesuchende den kompletten SSH-Befehl auf irgendeine Art und Weise zukommen lassen. Am leichtesten fällt in der Regel die Adresse per Copy&Paste in eine E-Mail zu übertragen.

Sollte der Xserver hingegen nicht funktionieren, sodass ich nicht mit dem Hilfesuchenden vom Rechner aus per Chat oder E-Mail kommunizieren kann, behelfe ich mir hier meist mit der Bitte einfach das Fenster mit einem Smartphone abzufotografieren und mir den „Screenshot“ per Mail oder Chat zu schicken. In diesem Fall muss ich den doch recht länglichen Code zwar abtippen, ich vermeide jedoch Buchstaben oder Zahlendreher beim telefonischen durchgeben der Tmate-ID — Achtet dennoch drauf, dass gar nicht so einfach ist, den Unterschied zwischen „1“,“l“ und „I“ oder „O“ und „0“ zu erkennen.

Habt ihr das SSH-Kommando richtig eingegeben, landet ihr umgehend auf dem Rechner eures Gegenübers. Ein Passwort zum Login muss nicht eingeben werden. Das Terminalfenster stellt das dar, was der Hilfesuchende selbst in seinem Terminal (oder dem virtuellen Terminal, falls der Xserver nicht funktioniert) sieht — sollte euer Terminalfenster mehr Platz bieten, zeigt Tmate rund um den Inhalt des Gegenübers Punkte an. Da nur Text übertragen werden muss, funktioniert Tmate auch ohne Probleme über eine dünne Mobilfunkleitung.

Kommandos und deren Ausgaben werden unmittelbar übertragen. Für Reparaturaktionen, die Root-Rechte erfordern, muss euch der Hilfesuchende nicht zwingend das Root-Passwort oder sein Passwort für Sudo-Kommandos mitteilen, er kann bei Bedarf einfach selbst das Passwort eingeben. So muss man keine unangenehmen Fragen nach dem Root-Passwort stellen, wenn man sein Gegenüber weniger gut kennt. Zudem kann der Hilfesuchende selbst jederzeit eingreifen.

Wenn der Xserver wie hier im Beispiel im gezeigten Beispiel noch funktioniert, bräuchte man Tmate eigentlich nicht zwingend — schließlich gäbe es mit Teamviewer ja eine grafische Option, die ebenso zuverlässig funktioniert. Fährt die grafische Desktopumgebung allerdings nicht mehr hoch, kommt die Stunde von Tmate. Nicht desto trotz muss man den User dennoch ein wenig unter die Arme greifen, ganz so einfach ist der Weg zu einer Remote-SSH-Session via Tmate nämlich auch nicht. Ubuntu bietet hier mit dem Recovery-Modus jedoch ein gutes Werkzeug.

Der Recovery-Modus von Ubuntu als letztes Hilfsmittel

In meinem letzten Fall lief auf dem Ubuntu-Rechner einer in der Schweiz ansässigen Bekannten beim Update von Ubuntu 14.04 auf 16.04 etwas schief. Das Ergebnis: Beim nächsten Start lief der Xserver nicht mehr hoch und die Paketverwaltung war komplett aus dem Tritt; es ließen sich keine Pakete mehr installieren. Setzt der Hilfesuchende ein Ubuntu-System (alternativ Linux Mint, oder ein anderes Ubuntu-Derivat) ein, dann habt ihr mit dem Recovery Modus ein mächtiges Werkzeug an der Hand.

In diesen gelangt der User, indem er kurz nach dem Einschalten des Ubuntu-Rechners die Escape-Taste drückt (ruhig mehrmals, unmittelbar nach Einschalten des Computers). Es sollte das Grub-Menü erscheinen, in dem man über die Option Erweiterte Optionen für Ubuntu in ein weiteres Menü gelangt, in dem man die auf dem System installierten Kernel sieht. Der User soll den obersten Eintrag mit dem Zusatz (recovery mode) auswählen. Funktioniert dieser nicht, dann soll er den Rechner hart abschalten, neu starten und einen älteren Eintrag auswählen, der (hoffentlich) funktioniert.

Am Ende landet man in einem Wiederherstellungsmenü, wobei der „Dateisystemstatus“ erstmal auf „Nur Lesen“ steht. Zudem baut das System im Recovery Modus keine Netzwerkverbindung auf — Beides lässt sich mit der Option network / Netzwerk aktivieren korrigieren. Die Funktion schaltet die Netzwerkkarte ein, holt sich eine IP vom Router und bindet die Laufwerke des Rechners mit Schreib- und Leserechten ein. Beachtet, dass dies lediglich über kabelgebundenes Netzwerk so einfach funktioniert. Den Rechner im Recovery Modus per WLAN ins Netz zu hängen, verursacht in der Regel deutlich mehr Aufwand, als kurzzeitig ein Kabel zu ziehen oder den Rechner in die Nähe des Routers zu tragen, sodass man ihn direkt dort anstecken kann.

Wer „professionell“ seinen Kunden per Tmate Support anbieten möchte, kann den benötigten Server auch selbst hosten. Den entsprechenden Code gibt es auf Github, Hinweise zur Installation findet ihr auf der Homepage des Projekts (ganz am Ende) unter „Host your own tmate server“. Man braucht am Ende „nur“ einen kleinen Linux-Server im Netz. Für einfache Zwecke genügt wahrscheinlich schon ein Raspberry Pi, den man per DnyDNS aus dem Internet unter einer statischen Adresse erreichbar macht. Weiter untem auf der Homepage gibt es auch weiterführende Informationen wie Tmate eigentlich funktioniert.

Wichtig ist natürlich dass Java und das Java-Browser-Plugin sowohl auf der Server- wie auch Client-Seite installiert ist. Unter Ubuntu würde ich das persönlich über das Metapaket „ubuntu-restricted-extras“ machen. Ist Java installiert, dann bedient sich die Seite eigentlich wie von alleine.

Man gibt einen Namen ein, klickt auf Start und erlaubt das Ausführen des Java-Applets. Daraufhin bekommt man einen Link, den man per Chat oder Mail an den Helfenden bzw. Hilfesuchenden weiterleiten kann.

Dieser gibt den Link in seinen Browser ein, erlaubt wieder das Ausführen des Java-Applets und schon steht die Verbindung. Eingangs kann man nur den Desktop des Gegenübers sehen, optional lässt sich der Desktop auch „richtig“ freigeben, so dass man auch den Desktop des Anderen über das Internet steuern kann.

Die Installation von Window Switch ist eigentlich recht einfach. Für Windows und Mac OS stehen Setups bereit. Für Linux gibt es Pakete bzw. Paketquellen für alle gängigen Distributionen. Selbst für OpenSolaris oder FreeBSD gibt es fertig gebaute Pakete. Installationshinweise für alle Systeme findet Ihr auf der Homepage von Window Switch.

Für Ubuntu Maverick führe ich eine Installation als Beispiel durch, für andere Ubuntu-Versionen gibt es unter dem Link von oben einen „Generator“, der euch die nötigen Befehle für die Installation erzeugt.

$ sudo -s
$ wget -O - http://winswitch.org/gpg.asc | apt-key add -
$ echo "deb http://winswitch.org/ maverick main" > /etc/apt/sources.list.d/winswitch.list
$ apt-get update && apt-get install winswitch
$ exit

Nach der Installation findet ihr Window Switch im Anwendungmenü. Unter Windows dürft Ihr nicht vergessen Apples Zeroconf zu installieren, nur so finden sich eure Rechner ohne euer zutun. Zur Funktionsweise könnte ich nun tausend Worte verlieren, oder euch einfach auf den Quick-Start Guide oder auf das Demo-Video verweisen, das ich hier im Folgenden eingebettet habe:

In meinem Test (Ubuntu Maverick und Windows 7) hat Window Switch nicht so schnell reagiert, wie im Video demonstriert wird. Ich konnte zwar Anwendungsfenster von einem Rechner auf den anderen schieben, doch es dauerte fast eine Minute bis eine auf RechnerA gestartete Anwendung auf RechnerB auftauchte.

Von daher bin ich von Window Switch nicht wirklich überzeugt. Wenn ich regelmäßig ein Anwendungfenster von einem Linux-System auf einen Windows-Rechner übertragen müsste, dann würde ich gleich Xming einrichten und für die restlichen Fälle tun die „normalen“ VNC-Client/Server auch ihren Zweck. Dennoch kann Window Switch vielleicht für deinen einen oder anderen interessant sein.

Nach wie vor gibt es von TeamViewer auf der Homepage deb- und rpm-Pakete zum Download, über die sich das Programm problemlos installieren lässt. Wer den alten TeamViewer 5 auf seinem Rechner hat, der sollte im Vorfeld über die Paketverwaltung die alte Version deinstallieren. Beim Update wird das TeamViewer-Paket nicht einfach aktualisiert, da die Paketnamen „teamviewer5“ und „teamviewer6“ lauten.

Zu TeamViewer und dem Linux-Port des Programms möchte ich eigentlich keine großen Worte verlieren. Die meisten Leser hier dürften das Programm kennen und an der Tatsache, dass TeamViewer für Linux „nur“ ein per angepasstes Wine lauffähiges Windows-Programm ist, hat sich auch noch nichts geändert. Alles weitere kann man daher hier im alten Artikel zur ersten Beta nachlesen.

Eine interessant Neuerung ist dagegen der Android-Client von TeamViewer. Das Programm kann man nicht über den Android-Market installieren. Stattdessen findet man auf der Homepage von TeamViewer unter „Mobile“ einen Link inkl. QR-Code zu einer apk-Datei, die sich dann von Hand installieren lässt.

Generell funktioniert das Steuern des Desktops über das Smartphone erstaunlich gut. Sogar über die 3G-Verbindung ist die Geschwindigkeit akzeptabel. Möglich wird das durch eine Reduktion der Bildqualität. Sieht das Desktop-Bild auf dem Handy bei einer WLAN-Verbindung praktisch perfekt aus, so wird bei einer Handy-Verbindung die Anzahl der Farben automatisch reduziert, was natürlich kein Nachteil ist, immerhin wird dabei das zur Verfügung stehende Datenvolumen nicht unnötig strapaziert.

Problematisch ist jedoch die Zusammenarbeit mit der alternativen Android-Tastatur Swiftkey. TeamViewer merkt nicht wenn ein angefangenes Wort per Vorschlag komplettiert wird oder löscht einen halben Satz, wenn man auch nur einmal auf Backspace drückt. Andere Android-Keyboards habe ich nicht getestet, eventuell muss man also auf die „Original-Tastatur“ ausweichen.

Bislang war TeamViewer jedoch nur in der Windows- und Apple-Welt zu Hause, doch seit kurzem offeriert die TeamViewer GmbH nun auch eine Beta für Linux. Der Hersteller offeriert Pakete für praktisch alle populären Linux-Distributionen. Dabei wird vorbildlich eine 32-bit, wie auch eine 64-bit Version angeboten. Bei Ubuntu lässt sich das .deb Paket mit einem Doppelklick installieren. Alternativ gibts auch ein .tar.gz Archiv mit vorkompilierten Binaries.

Nach der Installation könnt Ihr TeamViewer über „Anwendungen -> Internet -> TeamViewer“ über das Menü starten. Ich persönlich habe das Programm noch nie verwendet, von daher kann ich nicht viel zur Bedienung sagen, doch es sieht letztendlich genauso wie die Windows-Version aus… (Dazu gleich mehr).

Wer darauf tippt, dass TeamViewer für Linux ein ordentlicher Port des TeamViewers für Linux ist, den muss ich jedoch enttäuschen. Ähnlich wie bei Picasa für Linux wurde nur dafür gesorgt dass das Programm mittels Wine läuft und Wine mit ins Paket genommen (Früher lief TeamViewer zwar auch schon unter Wine, doch nur der Client-Teil funktionierte. Es war nicht möglich den eigenen Desktop freizugeben). Nichts desto trotz. Anwender, die TeamViewer unter Linux vermisst haben, wird es wohl nun freuen dass es eine „richtige“ Version für Linux gibt.

Ich persönlich bleibe bei meinem eigenen Helpdesk. Eine Portweiterleitung ist zuhause schnell eingerichtet und ich muss mir keine Sorgen machen, dass ich gegen die „nur für den Privatgebrauch kostenlos“-Lizenz verstoße.

[UPDATE]Hab die Linux-Version von TeamViewer noch schnell einem kleinen Test „Linux zu Linux“-Test unterzogen. Das Programm funktioniert wie versprochen. Die Hauptfunktionalität „Desktop-Anzeigen“ klappt natürlich, aber auch Chat und Telefonie via VoIP klappt ohne große Probleme.[/UPDATE]

Im Linux-Client ist die neue Funktion gut versteckt. Ihr findet die Desktopfreigabe wenn Ihr ein Gespräch startet unter der blauen Schaltfläche, die bisher ein Videogespräch startete. Ihr habt die Möglichkeit nur einen Ausschnitt oder den kompletten Desktop zu übertragen.

Weitere Neuigkeiten und Änderungen findet man im Changelog. Die weiteren als Neuigkeit angeführten Features konnte ich entweder nicht entdecken oder sie sind einfach zu unspektakulär als dass man über sie schreiben könnte  Pakete für alle großen Linux-Distributionen findet Ihr auf der Download-Seite von Skype, das „+“ hinter Ubuntu 8.10+ 32-bit oder Fedora 10+ heißt übrigens dass das Paket ab der genannten Version benutzt werden kann, nicht dass sich jemand fragt, warum Skype nur Pakete für „veraltete“ Linux-Distributionen anbietet.

Ein klarer Fall für VNC, doch was macht man wenn – wie heutzutage üblich – das NAT eines Hardware-Routers im Weg steht? Jemandem die Einrichtung einer Portweiterleitung auf einem unbekannten DSL-Router über das Telefon zu erklären ist ein Ding der Unmöglichkeit. Die Lösung dazu nennt man „Reverse-VNC“, dabei baut der VNC-Server zu einem VNC-Client, der im „Listen“-Modus gestartet wurde, aktiv eine Verbindung auf. Auf der Serverseite ist somit keine Portweiterleitung mehr nötig, diese ist nun auf der Seite des Clients – sollte man selber hinter einem Router sitzen – Pflicht. So umgeht man das einrichten einer Portweiterleitung beim „Kunden“.

Die c’t hat dem Thema letztes Jahr einen recht ausführlichen Artikel gewidmet, allerdings gibt es ein paar Stolpersteine, die es zum Umgehen gilt. Dazu ein paar Tipps.

Was braucht man?

Portweiterleitung

Sollte man selber hinter einem Router sitzen, so muss man einen Port vom Router auf den eigenen Rechner weiterleiten. Üblicherweise ist dies für VNC der Port 5500.

DynDNS-Adresse

Im Laufe dieses Artikels muss die eigene Internet-IP in einem Programm fest verdrahtet werden. Da die meisten DSL-Anbieter jedoch nach 24h die Einwahlverbindung trennen und beim erneuten Aufbau der Verbindung eine neue IP zugewiesen wird, macht es wenig Sinn eine IP einzutragen.

Dies lässt sich mit so genannten DynDNS-Anbietern umgehen. Diese – meist kostenlosen – Dienstleister verknüpfen die eigene Internet-IP mit einem Domainnamen. Ein kleines Programm auf dem eigenen Rechner (oder dem DSL-Router) aktualisiert die IP nach einem Wechsel beim DynDNS-Provider. Dadurch ist der eigene Rechner immer unter einer festen URL zu erreichen. Weitere Infos finden sich beispielsweise hier im Wiki von ubuntuusers.de.

Der „One-Click“ VNC-Server

Das alles war bislang nur „Vorspiel“. Nun geht es darum einen speziell angepassten VNC-Server zu erstellen bzw. den VNC-Server unseres Kunden mit den passenden Optionen zu starten. Um es dem Kunden so leicht wie möglich zu machen, wird ein VNC-Server erstellt, der einfach nur ausgeführt werden muss. Der Hilfesuchende muss rein gar nichts einstellen.

Windows/MacOS X

uVNC bietet dafür den PCHelpWare VNC-Server an. Allerdings muss man diesen von Hand über Konfigurationsdateien anpassen. Aufgrund der schlechten Dokumentation ein etwas mühseliges Unterfangen.

Praktischer ist ein Webtool der c’t. Hier müssen nur die eigene DynDNS-Adresse und ein paar erklärende Text eingefügt werden und mit einem Click erzeugt man den Server. Die generierte .exe Datei kann man dem Hilfesuchenden zukommen lassen.

Ist die Datei beim Kunden angekommen, so muss die .exe einfach nur über einen Doppelklick ausgeführt werden. Über einen weiteren Doppelklick auf die Verbindung wird die VNC-Verbindung aufgebaut. Allerdings muss dazu erst der eigene VNC-Client in dem „listen“-Modus gestartet werden, dazu gleich mehr. Der Server muss weder installiert, noch konfiguriert noch – nach Gebrauch und hoffentlich erfolgreicher Problemlösung – deinstalliert werden. Einfach die .exe Datei löschen reicht.

Hinweis: So gut wie jeder Virenscanner meldet bei solchen VNC-Server einen Trojaner. Klar, die Technik wird eben auch von den „Bösen“ angewendet. Daher ist es praktisch unmöglich die .exe per Email zu verschicken. Alle großen Email-Anbieter (ich habe web.de, GMX und Google Mail getestet) filtern das Attachment raus. Daher stellt man den VNC-Server am besten über einen Webserver zur Verfügung und verschickt nur die URL zur Datei.

Nun zum ersten Stolperstein. Der PCHelpWare VNC-Server arbeitet nur mit der Version 3.3 des VNC-Protokolls, die VNC-Client Programme von Linux jedoch nur mit der Version 4. Startet man also ein VNC-Viewer im Listen Modus, so sieht man außer

$ xtightvncviewer -listen 9500 -encodings "hextile copyrect"
xtightvncviewer -listen: Listening on port 15000
xtightvncviewer -listen: Command line errors are not reported until a connection comes in.
Connected to RFB server, using protocol version 3.8

nichts. Der Desktop des entfernten Rechners erscheint nicht auf dem eigenen Bildschirm. Die Optionen -encodings „hextile copyrect“ sollen angeblich helfen das Problem zu lösen, doch ich kann keine Besserung feststellen.

Die Lösung besteht aus der Installation einer vorkompilierten Version des RealVNC Viewers. Pakete und Archive für Linux lassen sich von hier nach einer Registrierung herunterladen. Hinter den Einträgen von

• VNC Enterprise Edition for Linux (x86), für 32-bit Linuxe
• VNC Enterprise Edition for Linux (x64), für 64-bit Linuxe

findet man Links zu einem „Debian Package“, das sich bequem in Ubuntu oder Debian installieren lässt. Allerdings beinhaltet das Paket den Server wie auch den Client. Alternativ kann man sich nur den Client als .tar.gz Archiv herunterladen.

• VNC Enterprise Edition Viewer for Linux (x86), für 32-bit Linuxe
• VNC Enterprise Edition Viewer for Linux (x64), für 64-bit Linuxe

Sollte man sich für das .deb Paket aus Client und Server entschieden haben, so kann man nun den Viewer über

$ vncviewer -listen 5500 -Protocol3.3

starten. Die Option -Protocol3.3 sagt dem Client dass das ältere Protokoll genutzt werden soll. Sollte man den reinen Client gewählt haben, so gilt das das Archiv zu entpacken, das Binary ausführbar zu machen und den Client dann zu starten

$ gunzip vnc-E4_4_3-x64_linux_viewer.gz
$ chmod +x vnc-E4_4_3-x64_linux_viewer
$ ./vnc-E4_4_3-x64_linux_viewer -listen 5500 -Protocol3.3

Von nun an können Hilfesuchende (Windows-User) uns mit ihren Fragen quälen. Solange ihr Internetzugang funktioniert bekommen sie den Client per Download von meinem Webserver, ich starte meinen VNC-Client und schon sehe ich ihren Desktop.

Linux

Tja fehlt nur noch Linux als System. Hier muss man nicht lange Frickeln. Linux bringt von Haus aus alles mit. Wichtig ist nur die Installation des x11vnc-Servers. Danach muss der Kunde nur ein Kommando ausführen.

$ sudo apt-get install x11vnc
$ x11vnc -connect dyndns.example.com

und der Helfer mit vncviewer -listen vorher seinen VNC-Client im Listen-Modus gestartet haben. Und schon sieht man seinen Desktop. Die Portweiterleitung und der Einsatz von DynDNS sind natürlich nach wie vor nötig. Viel Spaß mit dem höchstpersönlichen Helpdesk.

Noch ein Disclaimer: Natürlich gibt es kommerzielle Dienste wie TeamViewer und Co. die einen ähnlichen Service anbieten. Mir persönlich sind diese Dienste nicht sympatisch bzw. ich halte sie nicht für nötig. Mit dem „One-Click“ VNC-Server lässt sich das Thema ohne einen kommerziellen Dienst mit den Bordmitteln eines Linux lösen. Und Hilfesuchende mit Linux haben eh alles an Bord.