xrdp auf dem VPS: Ports, Tunnel und Sitzungen

xrdp auf dem VPS besteht aus drei Teilen

xrdp macht einen Linux-VPS über RDP erreichbar und lauscht dafür standardmäßig auf TCP-Port 3389. Hinter diesem Port stecken drei getrennte Bausteine, die unabhängig voneinander scheitern können. Erstens der RDP-Listener des Dienstes xrdp. Zweitens die grafische Sitzung, die xrdp-sesman startet, entweder ein Xorg-Server über das Modul xorgxrdp oder ein VNC-Server auf der Loopback-Adresse. Drittens die Desktop-Umgebung, die in dieser Sitzung laufen soll.

Diese Trennung erklärt die üblichen Symptome. Kommt gar keine Verbindung zustande, liegt es am Listener oder an einer Firewall. Erscheint die Anmeldemaske und bricht die Anmeldung danach ab, liegt es am Sitzungsmanager. Sehen Sie ein graues oder schwarzes Fenster, liegt es am dritten Baustein, und keine Firewall-Regel ändert daran etwas.

RDP (Remote Desktop Protocol) stammt von Microsoft. Windows-Clients sprechen es ohne Zusatzsoftware. VNC (Virtual Network Computing) ist ein älteres Protokoll für dieselbe Aufgabe. xrdp spricht nach außen RDP und benutzt intern je nach Konfiguration VNC. Welches Verfahren überhaupt zu Ihrem Anwendungsfall passt, klärt der Vergleich der Remote-Desktop-Verfahren auf einem Linux-VPS.

Welchen Port benutzt xrdp?

TCP 3389, und zwar auf allen Netzwerkschnittstellen. Der Wert steht in /etc/xrdp/xrdp.ini im Abschnitt [Globals].

[Globals]
port=3389
security_layer=negotiate

Prüfen lässt sich das auf dem Server selbst:

sudo ss -tlnp | grep -E 'xrdp|sesman'

Eine Zeile mit 0.0.0.0:3389 bedeutet, dass der Dienst Verbindungen von jeder Adresse annimmt. Eine zweite Zeile gehört zu xrdp-sesman, dem Sitzungsmanager. Er spricht kein RDP. Er nimmt die Anmeldedaten von xrdp entgegen, prüft sie über PAM (Pluggable Authentication Modules) und startet die X11-Sitzung. In xrdp 0.9.x, der Version in Ubuntu 24.04 (0.9.24, Stand September 2026), stehen in /etc/xrdp/sesman.ini die Zeilen ListenAddress=127.0.0.1 und ListenPort=3350, der Port ist also nur lokal erreichbar. Ab xrdp 0.10, wie in Ubuntu 26.04, läuft diese Verbindung über einen Unix-Socket, und Port 3350 verschwindet aus der Ausgabe.

Daraus folgt eine einfache Regel für die Fehlersuche: Genau ein Port dieses Aufbaus ist für Verbindungen von außen gedacht, und das ist 3389. Alles andere, was ss in diesem Zusammenhang zeigt, gehört auf die Loopback-Adresse 127.0.0.1. Wer die Ausgabe von ss noch nicht sicher liest, findet in der Einführung dazu, was ein Port unter Linux ist und welcher Prozess darauf lauscht, die nötigen Grundlagen.

Warum Port 3389 nicht offen im Internet stehen sollte

3389 gehört zu den am häufigsten gescannten Ports überhaupt, weil dahinter üblicherweise Windows-Server stehen. Jede Verbindung, die dort ankommt, landet bei der Anmeldemaske von xrdp. Diese prüft über PAM die normalen Linux-Konten des Servers. Ein schwaches Passwort eines beliebigen lokalen Benutzers genügt damit für eine grafische Sitzung mit dessen Rechten.

Dazu kommt das Zertifikat. Das Paket auf Debian und Ubuntu verlinkt /etc/xrdp/key.pem und /etc/xrdp/cert.pem auf das Snakeoil-Zertifikat unter /etc/ssl/private/ und /etc/ssl/certs/. Das ist ein selbst signiertes Zertifikat, das kein Client prüfen kann. Ihr RDP-Client zeigt deshalb bei jeder Verbindung eine Warnung, und Sie gewöhnen sich an, diese Warnung wegzuklicken. Genau darauf baut ein Angriff auf dem Übertragungsweg: Ein untergeschobenes Zertifikat sieht dann aus wie der Normalfall.

xrdp hinter einen SSH-Tunnel legen

SSH (Secure Shell) läuft auf dem Server ohnehin, und der Host-Schlüssel wird beim Verbinden geprüft. Der Tunnel nimmt xrdp aus dem öffentlichen Netz und macht diesen geprüften Kanal zum einzigen Weg hinein. Binden Sie den Listener zuerst auf die Loopback-Adresse. In /etc/xrdp/xrdp.ini:

[Globals]
port=127.0.0.1:3389

Der Parameter port akzeptiert die Form Adresse:Port. Ohne Adresse lauscht xrdp auf allen Schnittstellen, deshalb reicht die Zahl allein hier nicht.

sudo systemctl restart xrdp
sudo ss -tlnp | grep 3389

Die Ausgabe muss jetzt 127.0.0.1:3389 zeigen. Steht dort weiterhin 0.0.0.0:3389, hat der Dienst die geänderte Datei nicht gelesen oder ist beim Start gescheitert. sudo systemctl status xrdp und sudo journalctl -u xrdp -n 50 nennen den Grund.

Auf Ihrem Arbeitsrechner bauen Sie danach den Tunnel:

ssh -N -L 13389:127.0.0.1:3389 benutzer@vps.example.com

-L 13389:127.0.0.1:3389 heißt: Der lokale Port 13389 wird über die SSH-Verbindung an 127.0.0.1:3389 auf dem Server weitergereicht. -N verhindert, dass zusätzlich eine Shell geöffnet wird. Die lokale Portnummer ist frei wählbar, und ein Wert über 1024 kommt ohne Root-Rechte aus. Der RDP-Client verbindet sich dann auf localhost:13389, unter Windows also mit mstsc und localhost:13389 im Feld für den Computer, unter Linux zum Beispiel mit xfreerdp /v:localhost:13389 /u:benutzer. In FreeRDP 3 heißt das Programm xfreerdp3.

Ein Detail, das leicht übersehen wird: ssh -L bindet den lokalen Port auf Ihrem Rechner ebenfalls nur an Loopback. Mit -g oder mit GatewayPorts yes geben Sie ihn im lokalen Netz frei und öffnen damit genau das Loch wieder, das Sie auf dem Server geschlossen haben.

Was der Tunnel schützt und was nicht

Der Tunnel schützt gegen Angriffe aus dem offenen Netz. Automatisierte Scans und Anmeldeversuche erreichen die xrdp-Anmeldemaske nicht mehr. Eine Schwachstelle in xrdp oder in seinem TLS-Stack (Transport Layer Security) ist ohne gültigen SSH-Zugang nicht ansprechbar. Das Zertifikatsproblem entschärft sich, weil die Vertrauensentscheidung beim geprüften SSH-Host-Schlüssel liegt und nicht beim weggeklickten RDP-Dialog.

Der Tunnel schützt nicht den Desktop selbst. Jede Person mit SSH-Zugang auf dem Server kann denselben Tunnel aufbauen, ein schwaches Kontopasswort bleibt also ein schwaches Kontopasswort. Ein kompromittierter Arbeitsrechner sieht die komplette Sitzung, weil sie dort entschlüsselt ankommt. Schadsoftware, die Sie in der Sitzung starten, läuft mit Ihren Benutzerrechten weiter. Der Tunnel verschiebt die Angriffsfläche auf SSH, und deshalb gehört er zusammen mit Schlüsselanmeldung und abgeschaltetem Passwort-Login, also mit allem, was unter SSH auf einem VPS absichern steht.

Wenn der Port doch direkt erreichbar sein muss, etwa weil ein Client keinen Tunnel aufbauen kann, dann begrenzen Sie ihn auf bekannte Quell-Adressen:

sudo ufw allow from 203.0.113.10 to any port 3389 proto tcp
sudo ufw status verbose

Bei den meisten Anbietern gibt es zusätzlich eine Firewall im Kundenportal, die vor dem Server liegt und getrennt gepflegt wird. Eine Freigabe muss also an zwei Stellen stimmen. Die Syntax und die Reihenfolge der Regeln erklärt die Einführung in ufw auf dem VPS, und wenn Sie den Überblick über den Ist-Zustand brauchen, hilft die Anleitung, aktive Firewall-Regeln unter Ubuntu aufzulisten.

Was ist 127.0.0.1:5901?

Diese Adresse taucht in vielen Suchanfragen auf, und sie stammt in den meisten Fällen nicht von xrdp. VNC-Server rechnen ihren Port aus 5900 plus Displaynummer. Ein mit vncserver :1 gestarteter Server belegt also 5901. Das ist ein eigenständiger VNC-Server, der oft aus einer anderen Anleitung stammt.

Das VNC-Backend von xrdp rechnet anders. In /etc/xrdp/sesman.ini steht X11DisplayOffset=10, damit die Sitzungen nicht mit einem echten X-Server auf Display :0 kollidieren. Die erste xrdp-Sitzung bekommt deshalb Display :10, und ein Xvnc-Backend lauscht dann auf 5910. xrdp-sesman startet es mit dem Parameter -localhost, es nimmt also nur Verbindungen von 127.0.0.1 an, und im Abschnitt [Xvnc] von /etc/xrdp/xrdp.ini steht passend dazu ip=127.0.0.1.

Mit dem anderen Backend gibt es überhaupt keinen VNC-Port. Der Abschnitt [Xorg] benutzt das Modul aus dem Paket xorgxrdp und startet Xorg mit -nolisten tcp, die Verbindung läuft über einen Unix-Socket. Auf Ubuntu ist das der übliche Eintrag in der Auswahlliste der Anmeldemaske, sofern das Paket installiert ist.

So ordnen Sie einen gefundenen Port zu:

sudo ss -tlnp | grep ':59'
ps -ef | grep -i vnc

Sehen Sie 127.0.0.1:5901 und dazu einen Xvnc- oder Xtigervnc-Prozess, der nicht unter xrdp-sesman hängt, dann läuft ein zweiter, eigenständiger Fernzugriff auf dem Server. Das ist kein Fehler, aber es ist ein weiterer Dienst, den Sie aktuell halten müssen. Zeigt die Ausgabe dagegen 0.0.0.0:5901, steht dieser Desktop offen im Netz. Ein eigenständiger TigerVNC-Server bleibt nur dann auf Loopback beschränkt, wenn er mit -localhost yes gestartet wurde. Das klassische VNC-Passwort ist außerdem auf acht Zeichen begrenzt, taugt also nicht als einzige Hürde im Internet.

Ohne Desktop-Umgebung bleibt die Sitzung leer

Ein frisch installierter VPS hat keine grafische Oberfläche, und xrdp bringt selbst keine mit. Ohne Desktop-Umgebung meldet sich der Client an, die Sitzung startet, und sie endet sofort wieder, weil kein Programm läuft, das ein Fenster zeichnen könnte.

sudo apt update
sudo apt install -y xrdp xfce4 xfce4-goodies dbus-x11

XFCE ist auf einem Server die pragmatische Wahl. Es braucht wenig Arbeitsspeicher und kommt ohne Grafikbeschleunigung aus. GNOME unter Wayland funktioniert mit dem X11-Backend von xrdp nicht, und der Umbau lohnt sich auf einem Server ohne Bildschirm selten. Das Paket dbus-x11 liefert dbus-launch, das ältere Sitzungsskripte erwarten.

Danach legen Sie fest, welcher Desktop startet:

echo "startxfce4" > ~/.xsession
sudo systemctl restart xrdp

Die Kette dahinter ist kurz, und jeder Schritt darin ist eine eigene Fehlerquelle. xrdp-sesman startet /etc/xrdp/startwm.sh. Dieses Skript ruft /etc/X11/Xsession auf. Xsession arbeitet die Skripte in /etc/X11/Xsession.d ab und führt dabei ~/.xsession aus, weil in /etc/X11/Xsession.options bei Debian und Ubuntu die Zeile allow-user-xsession steht. Sobald der so gestartete Befehl endet, endet auch die Sitzung, und der Client trennt die Verbindung.

Zwei Folgerungen ergeben sich daraus. Erstens gilt ~/.xsession pro Benutzer: Melden Sie sich mit einem zweiten Konto an, das diese Datei nicht hat, bekommt dieses Konto einen leeren Bildschirm, während Ihr eigenes Konto einwandfrei funktioniert. Zweitens muss die Datei nicht ausführbar sein, weil Xsession sie in diesem Fall mit /bin/sh startet.

Es gibt zwei Alternativen dazu. In /etc/xrdp/sesman.ini sorgen EnableUserWindowManager=true und UserWindowManager=startwm.sh dafür, dass eine Datei ~/startwm.sh im Home-Verzeichnis Vorrang vor der systemweiten Variante bekommt. Systemweit können Sie stattdessen /etc/xrdp/startwm.sh bearbeiten, allerdings ist das eine Konfigurationsdatei des Pakets, und dpkg fragt bei jedem Update nach, was mit Ihrer geänderten Fassung geschehen soll.

Der Dialog zur Farbverwaltung nach der Anmeldung

In einer XFCE-Sitzung über xrdp erscheint häufig ein polkit-Fenster, das eine Legitimierung für ein color managed device verlangt, je nach Systemsprache übersetzt. Der Dienst colord fragt beim Start nach einer Berechtigung, die in einer Fernsitzung niemand erteilen kann, und der Dialog kommt bei jeder Anmeldung wieder. Eine Regel erledigt das:

// /etc/polkit-1/rules.d/49-colord-xrdp.rules
polkit.addRule(function(action, subject) {
    if (action.id.indexOf("org.freedesktop.color-manager.") === 0) {
        return polkit.Result.YES;
    }
});

Danach sudo systemctl restart polkit. Sie geben damit etwas auf: Jede Sitzung auf diesem Server darf Farbprofile anlegen und ändern, ohne zu fragen. Auf einem Server ohne Drucker und ohne kalibrierten Monitor ist das eine kleine Einbuße, aber es ist eine.

Wichtig für neuere Systeme: Auf Ubuntu 24.04 und später wirken die alten .pkla-Dateien nicht mehr. polkit 124 hat die Local Authority in das Paket polkitd-pkla ausgelagert, das nicht vorinstalliert ist. Anleitungen, die eine Datei unter /etc/polkit-1/localauthority/50-local.d/ anlegen lassen, laufen dort ins Leere, ohne dass eine Fehlermeldung erscheint.

Die Logs in der richtigen Reihenfolge lesen

Drei Protokolle, in der Reihenfolge des Verbindungsaufbaus.

Das erste sehen Sie im Client. Die Anmeldemaske von xrdp zeigt ein Textfeld mit Zeilen wie connecting to sesman on ..., sesman connect ok und sending login info to session manager, please wait.... Bleibt es bei Error connecting to sesman on ..., läuft xrdp-sesman nicht. Erscheint Can't create session for user ... - ..., hat sesman geantwortet und die Sitzung abgelehnt, und der Text hinter dem Benutzernamen nennt den Grund. Login retry limit reached heißt, dass die erlaubten Versuche verbraucht sind. Die Zeile Close the log window to exit. beendet nur das Fenster und ist keine Fehlermeldung.

Das zweite ist /var/log/xrdp.log, das Protokoll des RDP-Frontends mit den Protokoll- und TLS-Fehlern. Eine Zeile wie Error loading TLS private key from /etc/xrdp/key.pem, in älteren Versionen sinngemäß cannot read /etc/xrdp/key.pem. Permission denied, hat einen festen Grund: /etc/xrdp/key.pem verweist auf /etc/ssl/private/ssl-cert-snakeoil.key, und diese Datei gehört root:ssl-cert mit Modus 640. Der Dienst läuft als Benutzer xrdp und wird bei der Installation nicht in diese Gruppe aufgenommen.

sudo adduser xrdp ssl-cert
sudo systemctl restart xrdp

Das dritte ist /var/log/xrdp-sesman.log, zusammen mit den Protokolldateien im Home-Verzeichnis des angemeldeten Benutzers. xrdp-sesman startet den X-Server mit -logfile .xorgxrdp.%s.log, für Display :10 finden Sie also ~/.xorgxrdp.10.log. Die Fehler der Desktop-Umgebung selbst stehen in ~/.xsession-errors. Wenn die Anmeldung durchläuft und der Bildschirm trotzdem leer bleibt, ist das die Datei mit der Antwort.

Getrennte Sitzungen laufen weiter

Schließen Sie das RDP-Fenster, endet die Sitzung nicht. Die Prozesse laufen weiter, und bei der nächsten Anmeldung mit demselben Konto verbindet xrdp Sie wieder mit derselben Sitzung. Das ist im Alltag bequem, und es bedeutet, dass ein vergessener Browser wochenlang Arbeitsspeicher belegt. In /etc/xrdp/sesman.ini steuern KillDisconnected und DisconnectedTimeLimit dieses Verhalten. Der Standard von KillDisconnected ist false, beide Werte wirken nur mit xorgxrdp-Sitzungen, und Zeitangaben unter 60 Sekunden werden auf 60 angehoben.

Wenn mehrere Personen regelmäßig eine grafische Sitzung brauchen, wird das Tunneln pro Person schnell mühsam. Dann ist ein eigener Vermittlungsdienst die ruhigere Lösung, zum Beispiel ein selbst betriebener RustDesk-Relay-Server, bei dem die Clients ausgehend verbinden und kein Desktop-Port am VPS offen steht.

FAQ

Welchen Port benutzt xrdp standardmäßig?

TCP 3389, auf allen Netzwerkschnittstellen. Der Wert steht als port=3389 im Abschnitt [Globals] von /etc/xrdp/xrdp.ini. Mit port=127.0.0.1:3389 lauscht der Dienst nur noch auf der Loopback-Adresse und ist ausschließlich über einen SSH-Tunnel erreichbar. Der Sitzungsmanager xrdp-sesman ist ein zweiter Prozess: In xrdp 0.9.x lauscht er auf 127.0.0.1:3350, ab xrdp 0.10 benutzt er einen Unix-Socket. Für Verbindungen von außen ist er in keiner Version gedacht.

Warum bleibt der Bildschirm nach der Anmeldung an xrdp schwarz oder grau?

Weil die Sitzung startet, aber kein Fenstermanager läuft. xrdp-sesman ruft /etc/xrdp/startwm.sh auf, dieses Skript ruft /etc/X11/Xsession auf, und dort wird ~/.xsession des angemeldeten Benutzers ausgeführt. Endet der darin gestartete Befehl sofort, endet auch die Sitzung. Installieren Sie eine Desktop-Umgebung, etwa mit sudo apt install -y xfce4 xfce4-goodies, schreiben Sie startxfce4 in ~/.xsession und starten Sie xrdp neu. Die Datei gilt pro Benutzer, ein zweites Konto braucht also eine eigene. Den genauen Grund nennt ~/.xsession-errors.

Was läuft auf 127.0.0.1:5901, wenn ich xrdp installiert habe?

Mit hoher Wahrscheinlichkeit ein separat installierter VNC-Server, denn VNC belegt 5900 plus Displaynummer, und vncserver :1 ergibt 5901. Das Xvnc-Backend von xrdp beginnt dagegen bei Display :10, weil in /etc/xrdp/sesman.ini X11DisplayOffset=10 steht, und lauscht damit auf 5910 und aufwärts, gestartet mit -localhost. Benutzt xrdp das Backend [Xorg] mit dem Modul xorgxrdp, gibt es gar keinen VNC-Port, weil Xorg mit -nolisten tcp läuft. Mit sudo ss -tlnp | grep ':59' und ps -ef | grep -i vnc ordnen Sie den Port dem richtigen Prozess zu.

Ist xrdp durch einen SSH-Tunnel sicher?

Der Tunnel entfernt den öffentlichen Angriffspunkt. Scanner und automatische Anmeldeversuche erreichen die xrdp-Anmeldemaske nicht mehr, und die Vertrauensentscheidung liegt beim geprüften SSH-Host-Schlüssel statt beim selbst signierten RDP-Zertifikat. Der Desktop selbst wird dadurch nicht sicherer. Wer einen SSH-Zugang auf dem Server hat, baut denselben Tunnel auf, ein schwaches Kontopasswort bleibt also ein Risiko. Ein kompromittierter Arbeitsrechner sieht die gesamte Sitzung im Klartext. Sichern Sie deshalb den SSH-Zugang mit Schlüsselanmeldung ab und schalten Sie die Passwortanmeldung dort aus.