Zum Inhalt springen

Xrdp/Problembehebung

Aus Foxwiki

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


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/

  1. 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

  1. Der xRDP-Dienst wurde neu gestartet, der Server wurde neu gestartet
  2. 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 xrdp.

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 ls -l /etc/xrdp/key.pem /etc/xrdp/cert.pem?

Das Zertifikat sollte root:root gehören und die Berechtigungen 644 haben. Der Schlüssel sollte root:xrdp 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 „$ chmod 644 /etc/xrdp/cert.pem” und „$ chmod 640 /etc/xrdp/key.pem” 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 chmod 640 ... und chown :xrdp 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:

chmod 644 /etc/xrdp/cert.pemchmod 640 /etc/xrdp/key.pemchown :xrdp /etc/xrdp/key.pem

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 /usr/share/doc/xrdp/README.Debian 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 xrdp.ini 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

adduser xrdp ssl-cert führt zum gleichen Ergebnis wie usermod -G ssl-cert xrdp.

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 ( sudo adduser xrdp ssl-cert ) oder Sie ändern die Gruppe, die Eigentümer des Schlüssels ist, in die Gruppe „xrdp” ( chown :xrdp /etc/xrdp/key.pem ), zu der der Benutzer „xrdp” gehört.

Die beiden anderen Befehle ( chmod 644 /etc/xrdp/cert.pem und chmod 640 /etc/xrdp/key.pem ) 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 sudo stat -L -c %a /etc/xrdp/key.pem und sudo stat -L -c %a /etc/xrdp/cert.pem 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

  1. https://github.com/neutrinolabs/xrdp/issues/2297
  2. https://pastebin.com/Su2igSwn
Abgerufen von „https://wiki.foxtom.de/index.php?title=Xrdp/Problembehebung&oldid=159115“