Mit Windows-Clients auf Linux-Server zugreifen

Fremde Welten

Auch wenn viele Firmen heute auf dem Server Linux einsetzen, ist die Workstation oft noch eine Windows-Maschine. Dumm, wenn es sogar den Administrator selbst erwischt. Mit Xrdp kann er die grafische Linux-Oberfläche auf seinen Windows-Desktop umleiten.

Der Remote-Desktop-Zugriff zwischen Windows und Linux verbraucht normalerweise eine ganze Menge Bandbreite, Zeit und Nerven. Wäre es nicht schön, wenn Windows-Benutzer genauso einfach grafisch auf Linux-Systeme zugreifen könnten wie auf andere Windows-Maschinen, und zwar am besten noch mit ein und derselben Anwendung. Mit Xrdp, das dieser Artikel näher vorstellt, rückt dieses Ziel in erreichbare Nähe.

Bei Xrdp handelt es sich um eine Open-Source-Implementierung des Remote-Desktop-Protokolls, das die Windows Terminal Services verwenden, um sich mit Windows-Desktops zu verbinden. Das Xrdp-Paket bringt das RDP-Protokoll auf den Linux-Rechner, indem es einen X-Server bereitstellt, der Verbindungen vom Rdesktop-Programm [1] und Windows-Terminalserver-Clients annimmt.

Hat sich der Anwender verbunden und authentifiziert, bekommt er auf der Windows-Maschine einen ganz normalen Linux-Desktop präsentiert. Der Vorteil an der RDP-Lösung ist, dass sie keinen X-Server auf dem Windows-Rechner erfordert und das Linux-Display nicht exportiert werden muss.

Einen RDP-Server mit Linux aufzusetzen, ist einfach und dauert nur ein paar Minuten. Der frischgebackene Linux-Benutzer oder Windows-Administrator braucht nur Folgendes:

  • einen Benutzer-Account auf dem Linux-System
  • Remote-Zugang zum Linux-System, zum Beispiel über Secure Shell.
  • Root-Berechtigungen auf dem Linux-System.

Nach dem Herunterladen des Pakets von [2] und dem Entpacken genügt es, in das Verzeichnis zu wechseln und dort mit »make« die Übersetzung zu starten. Als Administrator installieren Sie die fertigen Programme mit »make install« . Die ausführbaren Dateien, Skripts und Bibliotheken wandern nach »/usr/local/xrdp« , die Konfigurationsdateien landen in »/etc/xrdp« .

Aus der Dokumentation wird nicht ganz klar, was nun als nächstes zu tun ist. Einiges Herumprobieren und der Email-Support durch einen der XRDP-Entwickler verhalfen im Test schließlich aber doch zum Erfolg. Wenn alles installiert ist, geben Sie als Administrator die folgenden Befehle ein:

cd /usr/local/xrdp
cp xrdp_control.sh /etc/init.d/xrdp_control
chkconfig --add xrdp_control
chkconfig xrdp_control on
service xrdp_control start

Das Skript »xrdp_control« ist dafür zuständig Xrdp zu starten und zu stoppen. Die Chkconfig-Aufrufe richten den automatischen Start im Rahmen des System-Boots ein. Der letzte Befehl startet schließlich die »sesman« - und »xrdp« -Dienste.

Um von einem Windows-Rechner aus auf den Linux-RDP-Dienst zuzugreifen, wählen Sie Start | Programs | Accessories | Communications | Remote Desktop Connection. Geben Sie dann den Hostnamen oder die IP-Adresse des Linux-Rechners ein, wie in Abbildung 1 zu sehen.

Abbildung 1: Herstellen einer Verbindung vom Windows-Rechner aus.

Es folgt ein Dialog, der zur Eingabe von Benutzername und Passwort auffordert (Abbildung 2). Hier geben Sie die Account-Daten auf dem Linux-Rechner ein. Selbst wenn Ihre Linux-Rechner Teil einer Active-Directory-Domain sind, müssen Sie jeden RDP-Benutzer extra anlegen. Dazu erzeugen Sie zuerst eine passende Benutzergruppe und fügen dann einzelne Accounts hinzu:

Abbildung 2: In diesem Windows-Dialog muss der Anwender seinen Benutzernamen und das Passwort auf dem Linux-Server eingeben.

groupadd rdpusers
useradd -g rdpusers ajones
passwd ajones

Existiert der User-Account »ajones« bereits, fügen der folgende Befehl ihn der Gruppe »rdpusers« hinzu:

usermod -G rdpusers ajones

Obwohl eine solche Gruppe keine echte Voraussetzung für RDP ist, vereinfacht sie die Administration.

Nach erfolgreicher Anmeldung erscheint der Bildschirm aus Abbildung 3, die im Log des Session-Managers die Verbindungsaufnahme zwischen Client und Server zeigt. Man kann dort sehen, dass der Session-Manager erst den RDP-Port kontaktiert, dann den VNC-Port, um schließlich den Desktop anzuzeigen.

Abbildung 3: Die Log-Datei des Xrdp-Session-Managers gibt einige Details über die Verbindungsaufnahme preis.

Unter der Haube

Auf dem Linux-Server laufen »xrdp« und »sesman« und warten auf eingehende Verbindungen. Wenn ein Windows-Terminalserver-Client sich verbindet, verhandeln Server und Client ein Verschlüsselungs-Level und tauschen schließlich kryptographische Schlüssel aus. Der Client gibt die Farbtiefe und die Auflösung des Desktops vor.

Gibt der Benutzer einen Benutzernamen und ein Passwort ein, startet die Authentifizierung. Das Modul »libvnc« wird geladen und eine Verbindung zur lokalen Adresse 127.0.0.1 oder der in »/etc/xrdp/xrdp.ini« spezifizierten Adresse aufgebaut. Die Authentifizierungsdaten sowie Bildschirmauflösung und Farbtiefe wandern an »sesman« weiter. Findet er eine passende Sitzung mit der angegebenen Auflösung/Farbtiefe, zeigt er sie dem Benutzer an. Andernfalls startet er eine neue Xvnc-Session mit den geforderten Werten.

Fazit

Xrdp ist leicht zu installieren, einzurichten und zu benutzen. Um damit zu arbeiten, braucht man keine jahrelange Linux-Erfahrung. Auf der Windows-Seite kommt man sogar ganz ohne Installation zusätzlicher Software aus.

Auch ohne aufwändige Analyse und Messungen gibt es einige Erfahrungswerte mit RDP-Sitzungen. Bei ungefähr zwei Dutzend gleichzeitig ist ein Maximum erreicht und die Arbeitsgeschwindigkeit sinkt spürbar. Davon abgesehen ist Xrdp eines der nützlichsten Tools in jedem Cross-Platform-Werkzeugkasten.

Der Autor

Ken Hess ist freier Technikredakteur und Journalist. Seine Themen reichen von Open Source über Linux, und Datenbanken bis hin zur Datenvisualisierung und Virtualisierung. Er bedankt sich bei Jay Sorg von Xrdp and Matt Chapman vom Rdesktop-Projekt für ihre Hilfe bei diesem Artikel.

Kommentare

Pfade

default build will install the following
/usr/local/lib/xrdp/
  libcommon.so
  libmc.so
  librdp.so
  libscp.so
  libvnc.so
  libxrdp.so
  libxup.so
/usr/local/bin/
  xrdp-genkeymap
  xrdp-keygen
  xrdp-sesadmin
  xrdp-sesrun
  xrdp-sestest
/usr/local/sbin/
  xrdp
  xrdp-sesman
  xrdp-sessvc
  xrdp-chansrv
/etc/xrdp/
  km-xxxx.ini
  sesman.ini
  rsakeys.ini
  startwm.sh
  xrdp.ini
  xrdp.sh
/etc/pam.d/
  xrdp-sesman
/usr/local/share/man/man5
  sesman.ini.5
  xrdp.ini.5
/usr/local/share/man/man8
  xrdp.8
  xrdp-sesman.8
  xrdp-sesrun.8
/usr/local/share/xrdp
  ad256.bmp
  cursor0.cur
  cursor1.cur
  sans-10.fv1
  xrdp256.bmp
when running, the following are created and written to
/var/run/
  xrdp.pid
  sesman.pid
/var/log/
  xrdp-sesman.log
/tmp
  xrdp*

Installation

Hallo,

 

habe bei der Installation das gleiche Problem mit "make"-Befehl.

Lösung steht im README:

 

since version 0.5.0 we switch to autotool to build xrdp
to build and install
change to the xrdp directory and run
./bootstrap
./configure
make
then as root
make install

 

 

lg

Klappt nicht

Klappt bei mir nicht:

make: *** Keine Targets angegeben und keine »make«-Steuerdatei gefunden.  Schluss.

Ist die Anleitung vielleicht veraltet, ok 2009 oder nicht Debian-kompatibel? Ich bräuchte für ein Java-Programm leider ein minimales Fenster.

Irgendwie fehlen mir hier auch die ganzen Abhängigkeiten/Voraussetzungen.

Probleme bei chkconfig

Bei chkconfig traten bei mir ein paar Probleme auf:

Den Befehl "chkconfig --add xrdp_control" wurde bei mir nur mit "/sbin/insserv Datei ober Verzeichnis nicht gefunden" quittiert.

Abhilfe schaffte "ln -s /usr/lib/insserv/insserv /sbin/insserv".

Danach verweigerte er trotzdem den Dienst: "/sbin/insserv failed, exit code 1".

Mit "chkconfig --add --force xrdp_control" liess er sich dann doch noch überreden.

Es funktioniert: "chkconfig --list xrdp_control" zeigt es.

Server und grafische Oberfläche geht gar nicht !

Das gute alte SSH2 geht mit Hilfe von Putty auch auf jeder Windowskiste.

Ich bin Unix/Linux Admin und würde nie einen Server mit grafischer Oberfläche betreiben !

Die Zielgruppe vom ADMIN-Magazin sollen doch sicher Admins sein, warum schreibt Ihr dann einen solchen Stümperkram, ala Klickbuntu-User-Wiki, frage ich mich !

Weshalb nicht, bitte?

@UnixoiD: Was bitte ist ein "verantwortungsbewusster Unix/Linux-ADMIN" und warum sollte er kein solches "Konstrukt" aufbauen?  Erstens ist der beschriebene Vorschlag kein "Konstrukt" sondern einen sinnvolle Verwendung freier Software und zweitens ist "verantwortungsbewusster Unix/Linux-ADMIN" ein informationsloser Gemeinplatz, welcher in einem fachlich fundierten Gespraech unter professionellen Admins tunlichst vermieden werden sollte.

RE: Vorheriges Kommentar

Es geht hier um den Aufbau eines Terminalservers, an dem Benutzer arbeiten können.

Nicht um einen produktiven Server, erst lesen dann antworten.

Linux-Server mit grafischer Oberfläche...

...ein verantwortungsbewusster Unix/Linux-ADMIN baut so einen Kontrukt nicht!

Und ich dachte, die Zielgruppe des ADMIN-Magazins sind ADMINs und keine Nixer?

Habe ich mich wohl doch geirrt...

comments powered by Disqus

Ausgabe 03/2013: Web Security

Anzeige