Xrdp/Problembehebung: Unterschied zwischen den Versionen

Version vom 20. Dezember 2025, 11:33 Uhr

Problembehebung

Der XRDP-Daemon startet nach einem Neustart nicht

xrdp.service log

[ERROR] trans_listen_address failed
[ERROR] xrdp_listen_main_loop: xrdp_listen_get_port failed

Dieser Fehler kann beim Systemstart auftreten, da XRDP versucht, sich an eine Netzwerkschnittstelle zu binden, die noch keine IP-Adresse erhalten hat

Lösung

Es muss ein Hilfsdienst erstellt werden, der auf die Initialisierung der Schnittstelle wartet. Dazu wird ein Skript unter dem Pfad /usr/local/sbin/wait-enp8s0.sh erstellt:

#!/bin/sh
IFACE="enp8s0"
ADDR="10.20.0.1"
TIMEOUT=60

i=0
while [ "$i" -lt "$TIMEOUT" ]; do
    if ip -4 addr show dev "$IFACE" | grep -q " $ADDR/"; then
        exit 0
    fi
    i=$((i+1))
    sleep 1
done

exit 1

Als nächstes muss die Datei ausführbar gemacht werden:

sudo chmod +x /usr/local/sbin/wait-enp8s0.sh

Erstellen einer Dienst-Unit /etc/systemd/system/wait-enp8s0.service:

[Unit]
Description=Wait for 10.20.0.1 on enp8s0
After=network.target
Wants=network.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/wait-enp8s0.sh
RemainAfterExit=yes

sudo systemctl daemon-reload

Schaffung einer Abhängigkeit des Hauptdienstes vom Hilfsdienst:

sudo systemctl edit xrdp

Inhalt der Datei:

[Unit]
After=wait-enp8s0.service
Requires=wait-enp8s0.service

Neustart des Dienstes

sudo systemctl daemon-reload

Weblinks

@@ Zeile 67: / Zeile 67: @@
-= TMP =
-=== Verwendung eines TLS-Zertifikats ===
-Da ich in diesem Bereich noch ziemlich unerfahren bin, habe ich mich entschlossen, diese GitHub-Anleitung zu verwenden, die mir eine nette Person in diesem Subreddit empfohlen hat: https://github.com/neutrinolabs/xrdp/wiki/TLS-security-layer
-Ich habe die GitHub-Anweisungen wie beschrieben befolgt, aber jetzt kann ich mich weder mit noch ohne SSH-Tunnel über xRDP einloggen.
-Zur Veranschaulichung: Ich verwende einen Ubuntu 20.04.4-Client, um auf einen Debian 11-Remoteserver zuzugreifen. Beide Rechner sind aktualisiert und befinden sich im selben VLAN.
-Hier sind die genauen Schritte, die ich auf meinem Debian-Server als Root durchgeführt habe:# Sicherheitsänderungen an xrdp.ini vorgenommen und xRDP neu gestartet
-tls_cipher=high
-security_layer=tls
-Das System wurde neu gestartet, es gab noch keine Probleme# Privaten Schlüssel und selbstsigniertes Zertifikat generieren
-$ openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 3650# Verschieben von key.pem (privater Schlüssel) und cert.pem (selbstsigniertes Zertifikat) nach /etc/xrdp/
-# Der Pfad zu key.pem und cert.pem wurde in xrdp.ini (global) angegeben
-certificate=/etc/xrdp/cert.pem
-key_file=/etc/xrdp/key.pem# Benutzer wurden zur Gruppe ssl-cert hinzugefügt
-# Der xRDP-Dienst wurde neu gestartet, der Server wurde neu gestartet
-# Die Anmeldung bei xRDP war nicht möglich, aber SSH funktionierte einwandfrei
-Zur Information hier meine xrdp.ini-Datei: https://pastebin.com/Su2igSwn
-Hier sind die Ausgaben, die ich erhielt, als ich security_layer von rdp auf tls umstellte: https://imgur.com/a/cgRqL7D
-Ich konnte das Problem vorübergehend beheben, indem ich in xrdp.ini (global) die Einstellung „security_layer” von „tls” auf „rdp” geändert habe. Danach funktionierte xRDP wieder.
-Irgendwelche Vorschläge?
-=== matt335672 kommentierte am 29. Juni 2022 ===
-Dateiberechtigungen?
-Unter Debian (es sei denn, Sie kompilieren aus dem Quellcode) läuft xrdp als Benutzer <tt>xrdp</tt>.
-Sie müssen sich nur um die Gruppe ssl-cert kümmern, wenn Sie die Standard-Debian-Zertifikate „snakeoil” verwenden. Wenn Sie Ihre eigenen Zertifikate einrichten, ist dies nicht erforderlich.
-Was erhalten Sie für <tt>ls -l /etc/xrdp/key.pem /etc/xrdp/cert.pem</tt>?
-Das Zertifikat sollte <tt>root:root</tt> gehören und die Berechtigungen 644 haben. Der Schlüssel sollte <tt>root:xrdp</tt> gehören und die Berechtigungen 640 haben.
-=== greped kommentierte am 30. Juni 2022 ===
-@matt335672 Vielen Dank, wenn ich den Befehl ausführe, sehe ich die folgenden Berechtigungen: -rw-r--r-- 1 root root 1558 26. Juni 22:57 /etc/xrdp/cert.pem-rw------ - 1 root root 1704 26. Juni 22:55 /etc/xrdp/key.pem
-Meiner Meinung nach sollte ich „<tt>$ chmod 644 /etc/xrdp/cert.pem</tt>” und „<tt>$ chmod 640 /etc/xrdp/key.pem</tt>” ausprobieren, richtig?
-=== metalefty kommentierte am 1. Juli 2022 ===
-Zusätzlich dazu
-chown :xrdp /etc/xrdp/key.pem
-=== matt335672 kommentierte am 1. Juli 2022 ===
-Das Zertifikat ist in Ordnung. Es ist für alle lesbar, wie es sein sollte, da es keine Geheimnisse enthält.
-Der Schlüssel enthält jedoch ein Geheimnis und muss daher für xrdp lesbar sein. Wenn Sie <tt>chmod 640 ...</tt> und <tt>chown :xrdp</tt> ausführen, wie @metalefty vorschlägt, sollten Sie folgendes Ergebnis erhalten:
--rw-r----- 1 root xrdp 1704 Jun 26 22:55 /etc/xrdp/key.pem
-Ist das verständlich?
-=== matt335672 kommentierte am 11. August 2022 ===
-Keine weiteren Beiträge – schließe.
-=== AvabAlexander kommentierte am 31. August 2022 ===
-Für alle, die googeln und dies finden. Ich hatte genau denselben Fehler und es hat bei mir funktioniert, nachdem ich diese vorgeschlagenen Befehle ausgeführt habe:
-<tt>chmod 644 /etc/xrdp/cert.pemchmod 640 /etc/xrdp/key.pemchown :xrdp /etc/xrdp/key.pem</tt>
-=== eliassal kommentierte am 12. November 2023 ===
-Fantastisch, das hat mir geholfen, mit xrdp auf mein Kalilinux 2023 Purple zuzugreifen. Ich habe die Anweisungen befolgt /1https://www.kali.org/docs/general-use/xfce-with-rdpbut, aber es blieb beim Starten des Dienstes hängen, und als ich versuchte, eine RDP-Verbindung zur Kali-Box herzustellen, wurde meine Anmeldung abgelehnt. Nachdem ich die drei Befehle ausgeführt hatte, funktionierte die RDP-Verbindung einwandfrei, vielen Dank also. Nochmals vielen Dank an @matt335672 für Ihre Hilfe.
-=== metalefty kommentierte am 12. November 2023 ===
-Ich glaube, es ist in <tt>/usr/share/doc/xrdp/README.Debian</tt> dokumentiert. Ich empfehle Ihnen, die distributionsspezifische README-Datei zu lesen, wenn Sie das Distributionspaket verwenden.
-https://salsa.debian.org/debian-remote-team/xrdp/-/blob/debian/0.9.21.1-1/debian/README.Debian?ref_type=tags
-=== eliassal kommentierte am 12. November 2023 ===
-@metalefty Danke, aber in dem von Ihnen angegebenen Link steht nur: „Erwägen Sie die Verwendung von TLS-Verschlüsselung anstelle der standardmäßigen RDP-Verschlüsselung ...“, aber es wird nicht erklärt, wie das geht (ich bin kein Sicherheitsexperte). Können Sie mir bitte sagen, wie das gemacht wird? Nochmals vielen Dank.
-=== metalefty kommentierte am 13. November 2023 ===
-Das steht definitiv dort!
-Vergessen Sie nicht, dass xrdp möglicherweise Mitglied der Gruppe ssl-cert sein muss, um Ihren privaten Schlüssel lesen zu können.
-=== eliassal kommentierte am 14. November 2023 ===
-@metalefty xrdp ist kein Benutzer, sondern eine Gruppe, und meines Wissens nach kann man einer Gruppe keine weitere Gruppe hinzufügen. Daher lautet meine Frage: „Wie macht man xrdp zum Mitglied von ssl-cert? Danke
-=== metalefty kommentierte am 14. November 2023 ===
-Ich bin nicht mit Kali Linux vertraut, aber xrdp ist zumindest unter Debian/Ubuntu ein Benutzer und auch eine Gruppe. Wir KÖNNEN also den Benutzer xrdp zur Gruppe ssl-cert hinzufügen.
-ubuntu@jammy:~$ id xrdp
-uid=114(xrdp) gid=123(xrdp) groups=123(xrdp)
-root@jammy:/etc/ssl/private# ls -l
-total 4
--rw-r----- 1 root ssl-cert 1704 Nov 14 08:12 ssl-cert-snakeoil.key
-Der folgende Befehl fügt den Benutzer xrdp zur Gruppe ssl-cert hinzu.
-root@jammy:/etc/ssl/private# usermod -G ssl-cert xrdp
-root@jammy:/etc/ssl/private# id xrdp
-uid=114(xrdp) gid=123(xrdp) groups=123(xrdp),122(ssl-cert)
-Es gibt auch eine Anleitung, die von Debian-Maintainern in <tt>xrdp.ini</tt> hinzugefügt wurde. Ich finde die vom Debian-Team hinzugefügten Dokumente sehr gut. Alle Debian-spezifischen SSL-Aspekte werden bereits in ihrer Dokumentation erklärt. Daher empfehle ich jedem, zuerst die Debian-Dokumentation zu lesen, wenn er xrdp auf einer Debian-basierten Distribution verwendet. https://salsa.debian.org/debian-remote-team/xrdp/-/blob/debian/0.9.21.1-1/debian/patches/document-certs.diff
-<tt>adduser xrdp ssl-cert</tt> führt zum gleichen Ergebnis wie <tt>usermod -G ssl-cert xrdp</tt>.
-root@jammy:/etc/ssl/private# id xrdp
-uid=114(xrdp) gid=123(xrdp) groups=123(xrdp)
-root@jammy:/etc/ssl/private# adduser xrdp ssl-cert
-Hinzufügen des Benutzers „xrdp” zur Gruppe „ssl-cert” ...
-Hinzufügen des Benutzers xrdp zur Gruppe ssl-cert
-Fertig.
-root@jammy:/etc/ssl/private# id xrdp
-uid=114(xrdp) gid=123(xrdp) groups=123(xrdp),122(ssl-cert)
-=== eliassal kommentierte am 14. November 2023 ===
-Vielen Dank @metalefty , OK, ich habe das getan und werde die Dokumentation lesen, aber sagen Sie mir, dass ich auch die 3 genannten Befehle ausführen muss: chmod 644 /etc/xrdp/cert.pem chmod 640 /etc/xrdp/key.pem chown :xrdp /etc/xrdp/key.pem
-=== metalefty kommentierte am 14. November 2023 ===
-Dann könnte es sich um ein Problem mit der Debian-Dokumentation handeln. Melden Sie es dem Debian-Team. Wir sind dafür nicht verantwortlich.
-Wie auch immer, Debian nimmt distributionsspezifische Anpassungen an SSL-Zertifikaten vor. Die Debian-Dokumentation zu befolgen, ist die gängigste Vorgehensweise, die Paketbetreuer erwarten. Wenn ihre Anleitung nicht funktioniert, melden Sie es ihnen.
-=== pharaonic-faery kommentierte am 3. Dezember 2023 ===
-@eliassal
-OK, ich habe die Dokumentation gelesen und werde sie noch einmal lesen, aber sagen Sie mir, dass ich auch die drei genannten Befehle ausführen muss: chmod 644 /etc/xrdp/cert.pem chmod 640 /etc/xrdp/key.pem chown :xrdp /etc/xrdp/key.pem
-Ich weiß nichts über Kali Linux, aber unter Debian ist das nicht notwendig. Der private SSL-Schlüssel gehört der Gruppe „ssl-cert”. Der Benutzer „xrdp” ist der Benutzer, der die Binärdatei „xrdp” ausführt und Zugriff auf den Schlüssel haben muss, wenn Sie eine TLS-Verbindung wünschen. Entweder fügen Sie den Benutzer „xrdp” zur Gruppe „ssl-cert” hinzu ( <tt>sudo adduser xrdp ssl-cert</tt> ) oder Sie ändern die Gruppe, die Eigentümer des Schlüssels ist, in die Gruppe „xrdp” ( <tt>chown :xrdp /etc/xrdp/key.pem</tt> ), zu der der Benutzer „xrdp” gehört.
-Die beiden anderen Befehle ( <tt>chmod 644 /etc/xrdp/cert.pem</tt> und <tt>chmod 640 /etc/xrdp/key.pem</tt> ) scheinen unnötig zu sein, da die beiden Dateien bereits über die Berechtigungen 644 (Zertifikat) und 640 (Schlüssel) verfügen (zumindest unter Debian). Wenn Sie sichergehen möchten, können Sie die Befehle <tt>sudo stat -L -c %a /etc/xrdp/key.pem</tt> und <tt>sudo stat -L -c %a /etc/xrdp/cert.pem</tt> ausführen.
-=== eliassal kommentierte am 18. März 2024 ===
-Hallo @metalefty , ich bin es wieder. Ich habe Kali Linux 2024 heruntergeladen und alle Schritte befolgt, aber ich erhalte immer noch die Meldung „Verbindung abgelehnt”. Ich dachte, es wäre ein Firewall-Problem. Ich habe
-ufw allow 3389/tcp ausgeführt, aber es scheint, dass keine Firewall installiert ist
-Ich erhalte immer die Meldung „Verbindung zum Host auf Port 3389 konnte nicht hergestellt werden”. Ich habe versucht, von einem Windows-Rechner aus eine Telnet-Verbindung zu Port 3389 herzustellen. Ich erhalte die Meldung „Verbindung zu 192.168.10.240...Verbindung zum Host auf Port 3389 konnte nicht hergestellt werden: Verbindung fehlgeschlagen”.
-Wenn ich den Port-Scanner ausführe, hört 3389 nicht, obwohl xrdp auf dem Kali-Linux-Rechner läuft. Mit
-netstat -tnlp | grep 3389
-erhalte ich keine Ergebnisse. Wie ist das möglich? Vielen Dank für Ihre Hilfe.
-=== eliassal kommentierte am 18. März 2024 ===
-Nachdem ich mich mit der Datei xrdp.ini beschäftigt hatte, sah ich port=vsock://-1:3389. Ich änderte dies in port=tcp://:3389 und hoffte, dass es funktionieren würde. Es funktionierte und ich konnte mich über RDP verbinden.
 === Weblinks ===