Workshop: Remote-Desktop-Verbindungen – Von Windows auf Linux-Desktops zugreifen oder von Linux auf die Oberfläche eines Windows-2003-Server macht mit dem richtigen Programm keine Mühe. Wird sie mit SSH getunnelt, ist die Fernverbindung sogar sicher.
Bei der Vielzahl grafischer Werkzeuge, die dem Administrator heute zur Seite stehen, möchte er auch Wartungsarbeiten oder eine Support-Anfrage aus der Ferne grafisch erledigen. Windows-Systeme enthalten mit Remote-Desktop und dem zugehörigen Protokoll RDP bereits eine passende Ausstattung. Allerdings ist die Konfiguration nicht frei von Tücken, und die mangelnde Interoperabilität mit anderen grafischen Desktop-Systemen lässt auch weitere Möglichkeiten interessant werden.
Der Workshop zeigt nicht nur, wie der Verwalter schnell zu einem funktionstüchtigen Remote-Desktop auf Windows kommt. Auch die Konkurrenten, NX von Nomachines und Real- respektive Tight-VNC lassen sich innerhalb von wenigen Minuten in Betrieb nehmen. Bei dieser Software sichert die Secure-Shell mit einem Tunnel die Verbindung zwischen lokalem und entferntem System. NX hat die SSH-Unterstützung bereits eingebaut. VNC ist hingegen auf einen externen SSH-Dienst wie »OpenSSH« angewiesen.
Der Fernzugriff über das Internet ist zwar bei Nutzung der SSH relativ sicher. Besser ist jedoch, wenn sich der Administrator zur Fernwartung via VPN mit dem Unternehmensnetzwerk verbinden kann und die grafische Interaktion durch diesen Tunnel leiten lässt. Die SSH kann als zusätzliche Absicherung bis zum Zielsystem fungieren.
Fernzugriff mit VNC
Einer der Klassiker für den grafischen Fernzugriff via IP ist VNC (Virtual-Network-Computing). Es setzt auf das Client/Server-Modell auf. Der Administrator muss VNC auf dem Server installieren. Der Client benötigt lediglich den Viewer, den es auch für Handhelds gibt. Die Java-Version eignet sich für den Zugriff via Webbrowser. VNC-Sitzungen lassen sich durch die Secure-Shell (SSH) tunneln, was ein Mindestmaß an Abhörsicherheit gewährt. Der VNC-Server verlangt zudem ein Passwort. Erst dann schaltet er die Verbindung frei.
VNC ist für eine Vielzahl Systeme erhältlich, darunter Windows, Linux und Mac OS X. Zudem unterstützt es diverse Unix-Varianten. Laden Sie sich die passende Version von »http://www.realvnc.com« herunter. Auf Linux können Sie das aktuelle Release bestimmt über den Paket-Manager Ihrer Distribution einspielen. Meist liefern die Distributionen ein Init-Skript mit oder fragen, ob der Anwender einen Eintrag für »xinetd« wünscht, damit der VNC-Server ohne weiteren Benutzereingriff startet.
Wichtig bei der Konfiguration ist nur, dass Sie ein ordentliches Passwort für die Nutzung des Servers eingeben. Denn wer auf den Server kommt, hat Zugriff auf das komplette System.
Starten Sie den VNC-Dienst »Xvnc« über das Perl-Skript »vncserver« ohne weitere Optionen. Die Verbindung lässt sich nun leicht mit SSH verschlüsseln. Sie geht dabei vom entfernten Client aus. Bauen Sie den SSH-Tunnel zwischen dem lokalen Port und TCP-Port 590x des VNC-Server auf:
ssh -C -L 5901:localhost:5900 vnc_s.firma.com
Die Option »C« komprimiert den Datenstrom per »gzip«, wodurch sich ein Windows- oder KDE-Desktop vielleicht auch durch eine langsame Verbindung ansprechen lässt. Die Windows-Version der SSH2 verlangt, dass die Kompression mit »+C« explizit eingeschaltet wird.
Der lokale TCP-Port 5901 wird zum entfernten Port 5900 getunnelt. Dort ist die erste Session (:0) des VNC-Servers erreichbar. Den lokalen Viewer binden Sie an den lokalen Port und Session 1 (Port 5901).
vncviewer localhost:1 lädt den Client. Nachdem Sie das Server-Passwort eingegeben haben, bekommen Sie schließlich den virtuellen Desktop zu sehen. Auf Unix-artigen Systemen lässt sich in der Datei »~/.vnc/xstartup« noch der gewünschte Desktop einstellen.
Das kostenlose VNC ist ein pfiffiges Werkzeug, das besonders für die Anwendung im LAN geeignet ist. Mit schmalbandigen Verbindungen kommt es nicht so gut zurecht. Hier soll der Administrator zur kostenpflichtigen Variante »RealVNC« greifen, die sich notfalls auch für Ferneinsätze über GSM nutzen lässt.
Das Netzwerk möglichst wenig zu belasten, haben auch die Macher von »TightVNC« im Sinn. Interessant ist die ebenfalls kostenlose VNC-Variante auch deshalb, weil sie ein Java-Applet offeriert, so dass der User die Server-Oberfläche im Webbrowser laden kann. Dazu ist im »vncserver«-Skript lediglich bei der Zeile
$cmd .= " -httpd $vncClasses"; das Kommentarzeichen zu entfernen, um die Java-Klassen freizuschalten.
Wem VNC zu langsam vorkommt, oder wer häufiger über Modem-Verbindungen auf den entfernten Server zugreifen muss, greift zum Terminalserver-Paket »FreeNX« der italienischen NoMachines NX Technology (www.nomachine.com). Die freie Variante ist kostenlos und unterliegt auch hinsichtlich der Anzahl der Client-Verbindungen keiner Beschränkung. Die kommerzielle Version enthält darüber hinaus Unterstützung für mehrere gleichzeitige Sitzungen, Sound und Zugriff auf SMB/Samba-Shares. Allerdings gibt es die Server-Version nur für Linux und Solaris. Windows- und Mac-OS-X-User können mit der Desktop-Verson also nur auf diese Systeme zugreifen.
NX ist darauf getrimmt, den bestmöglichen Durchsatz bei langsamen Verbindungen zu erzielen. Mehrere Kompressions- und Caching-Verfahren führen zu einer effizienten Nutzung der Bandbreite. So lassen sich durch NX getunnelte RDP- und VNC-Sitzungen beschleunigen.
Die NX-Kommunikation läuft standardmäßig über das SSH-Protokoll. Vorteil: Die Firewall muss lediglich einen einzigen Port durchlassen (Standard: Port 22), und der Transportweg ist nahezu automatisch gesichert. Haben Sie bereits vorher Public-Keys für eine SSH angelegt, können Sie diese Schlüssel auch importieren.
Bei der initialen Konfiguration erzeugen Sie einen Public-Key für den Standard-User »nx«, um die SSH-Verschlüsselung zu nutzen.
Führen Sie dazu das Setup mit der Option »setup-nomachine-key« aus:
nxsetup --install --setup-nomachine-key
Der öffentliche Schlüssel befindet sich in der Datei »~nx/.ssh/authorized_keys2«, der Sie einen bereits vorhandenen Schlüssel auch hinzufügen können.
Legen Sie dann noch einen Benutzer-Account speziell für Nomachine an:
nxserver --adduser anton
Den Benutzer »anton« gehört zur internen NX-Datenbank. Er taucht nicht in »/etc/passwd« auf.
Sofern TCP-Port 22 für die SSH-Verbindung verfügbar ist, können Sie sich nun bereits mit dem NX-Server verbinden. Falls der SSH-Server einen anderen Port nutzt, tragen Sie diesen in der Datei »/etc/nxserver/node.conf« ein.
Starten Sie den NX-Client. Die Einstellungen erreichen Sie über die »Configure«-Schaltfläche. Für eine direkte Verbindung stellen Sie den »Desktop« auf »Unix«. Wenn Sie »FreeNX« als Proxy-Dienst für Windows-RDP oder VNC einsetzen möchten, wählen Sie die entsprechende Option aus der Drop-down-Liste »Desktop«.
Um die Verbindungsstrecke nicht permanent zu belasten, beispielsweise bei einem langsamen Modem-Link, nutzt der Anwender die Suspend/Resume-Funktion über die Tastenkombination Strg+Alt+T.
Windows-RDP für Server
Windows-Betriebssysteme enthalten für den grafischen Fernzugriff das Protokoll RDP (Remote-Desktop-Protocol). Microsoft unterscheidet die drei Dienste Remote-Desktop, -Administration und -Assistence. Die Dienste lassen sich für den unaufgeforderten Zugriff konfigurieren. Die Sicherheitseinstellungen sind auf der Client- (2000/XP) und Server-Variante (2003) unterschiedlich zu ändern.
Die Remote-Administration dient dem Fernzugriff auf Windows-2003-Server. Das Verfahren arbeitet mit RPC (Remote-Procedure-Calls) und DCOM (Distributed-Component-Object-Model). So lassen sich MMC und WMI auch aus der Ferne nutzen.
Auf dem 2003-Server benötigt der Verwalter das gleiche Administrator-Konto wie auf der Workstation. Zudem muss die Gruppenrichtlinie für die »Remote-Unterstützung« entsprechend angepasst werden. In »Remote-Unterstützung anbieten« wählt der Administrator erst »Aktiviert« und dann »Helfer anzeigen«. Hier tragen Sie den Support-Account ein.
Die Windows-Firewall blockt standardmäßig die dynamischen Ports 1024 bis 1034, die der Client zugewiesen bekommt. Diese können Sie nur mit dem Kommando netsh firewall öffnen, da kein vorkonfigurierter Regelsatz in den grafischen Firewall-Einstellungen wählbar ist.
Auf Windows-Desktops zugreifen
Normalerweise ist für den Zugriff auf den entfernten Client-Desktop eine aufwändige Einladungsprozedur zu überstehen. Administratoren entgehen der Einladung, indem sie die Sitzung per URA (Unsolicited-Remote-Assistance) starten.
Wenn sich der Administrator in eine laufende Sitzung einschaltet (Remote-Assistence): Dazu ist ein Account mit Administrator-Rechten auf dem Client nötig. Fordert der Benutzer die Hilfe des Administrators über »Hilfe und Support« an, gibt Windows die notwendigen Ports 135, 445 und 3389 in der Desktop-Firewall automatisch frei.
Aber der Verwalter kann auch ohne diese Einladung auf den entfernten Windows-PC zugreifen. Dazu muss der Computer nicht einmal Mitglied einer Domäne sein. Gehen Sie auf dem Client zu den Ordneroptionen und deaktivieren auf dem Register »Ansicht« die »Einfache Dateifreigabe«. Erst dadurch kann sich der Fernbenutzer überhaupt anmelden.
Die Verbindung klappt über »Hilfe und Support«. Dort klickt der Administrator auf »Tools« und anschließend auf »Remote-Unterstützung anbieten«. Geben Sie den Netzwerknamen des Windows-PC an und klicken auf »Verbinden«. Wählen Sie noch aus der Liste den Benutzernamen aus, und die Hilfesitzung startet.
rdesktop: RDP für Linux
Nun haben manche Verwalter die Admin-Workstation bereits auf Linux oder BSD umgestellt und können nicht von Windows aus auf einen Windows-Desktop zugreifen. Müssen Sie auch nicht, denn für Unix-artige Systeme springt »rdesktop« in die Bresche. Es lässt sich nicht nur für den Support einsetzen. Der Administrator kann normalen Anwendern auch Zugriff auf grafische Windows-Programme geben. Den Zugang regeln die Windows-Terminal-Services. Mit dem Terminal-Server verbinden sich die Benutzer einfach per rdesktop Hostname
Sie bekommen den Windows-Anmeldebildschirm zu sehen, über den sich auch eine bestimmte Domäne ansprechen lässt. Verwenden Sie die Option »f«, geht das Fenster sofort in den Vollbildmodus.
Das Werkzeug »rdesktop« enthält nicht allzu viele Optionen. Interessant ist der Schalter »r«, mit dem sich lokale Ressourcen an die Fernsitzung binden lassen. Das ist komfortabel, wenn Sie eine lokale Druckerwarteschlange auf einen virtuellen Drucker in der Terminal-Sitzung abbilden möchten:
Drucken Sie nun in der Windows-Sitzung etwas aus, können Sie die lokale Warteschlange aus dem normalen Druckdialog von Windows auswählen. jr@networkcomputing.de