|
|
| (15 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| === Verwendung eines TLS-Zertifikats ===
| | '''Xrdp/Problembehebung''' |
| 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.
| | == Beschreibung == |
|
| |
|
| 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.
| | ==== XRDP-Daemon startet nach Systemneustart nicht ==== |
| | ; xrdp.service log |
| | [ERROR] trans_listen_address failed |
| | [ERROR] xrdp_listen_main_loop: xrdp_listen_get_port failed |
|
| |
|
| 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
| | Dieser Fehler kann beim Systemstart auftreten, da XRDP versucht, sich an eine Netzwerkschnittstelle zu binden, die noch keine IP-Adresse erhalten hat |
| tls_cipher=high
| |
| security_layer=tls
| |
|
| |
|
| Das System wurde neu gestartet, es gab noch keine Probleme# Privaten Schlüssel und selbstsigniertes Zertifikat generieren
| | ; Lösung |
| | Hilfsdienst erstellen |
| | * Auf Initialisierung der Schnittstelle warteen |
|
| |
|
| $ 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/
| | Skript |
| # Der Pfad zu key.pem und cert.pem wurde in xrdp.ini (global) angegeben
| |
|
| |
|
| certificate=/etc/xrdp/cert.pem
| | ''/usr/local/sbin/wait-enp8s0.sh'' |
| | <syntaxhighlight lang="bash" highlight="" copy line> |
| | #!/bin/sh |
| | IFACE="enp8s0" |
| | ADDR="10.20.0.1" |
| | TIMEOUT=60 |
|
| |
|
| key_file=/etc/xrdp/key.pem# Benutzer wurden zur Gruppe ssl-cert hinzugefügt
| | i=0 |
| # Der xRDP-Dienst wurde neu gestartet, der Server wurde neu gestartet
| | while [ "$i" -lt "$TIMEOUT" ]; do |
| # Die Anmeldung bei xRDP war nicht möglich, aber SSH funktionierte einwandfrei
| | if ip -4 addr show dev "$IFACE" | grep -q " $ADDR/"; then |
| | exit 0 |
| | fi |
| | i=$((i+1)) |
| | sleep 1 |
| | done |
|
| |
|
| Zur Information hier meine xrdp.ini-Datei: https://pastebin.com/Su2igSwn
| | exit 1 |
| | </syntaxhighlight> |
|
| |
|
| Hier sind die Ausgaben, die ich erhielt, als ich security_layer von rdp auf tls umstellte: https://imgur.com/a/cgRqL7D
| | * Als nächstes muss die Datei ausführbar gemacht werden: |
| | <syntaxhighlight lang="bash" highlight="1" copy line> |
| | sudo chmod +x /usr/local/sbin/wait-enp8s0.sh |
| | </syntaxhighlight> |
|
| |
|
| 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.
| | * Erstellen einer Dienst-Unit ''/etc/systemd/system/wait-enp8s0.service'': |
| | <syntaxhighlight lang="ini" highlight="" copy line> |
| | [Unit] |
| | Description=Wait for 10.20.0.1 on enp8s0 |
| | After=network.target |
| | Wants=network.target |
|
| |
|
| Irgendwelche Vorschläge?
| | [Service] |
| | Type=oneshot |
| | ExecStart=/usr/local/sbin/wait-enp8s0.sh |
| | RemainAfterExit=yes |
| | </syntaxhighlight> |
|
| |
|
| === matt335672 kommentierte am 29. Juni 2022 === | | <syntaxhighlight lang="bash" highlight="1" copy line> |
| Dateiberechtigungen?
| | sudo systemctl daemon-reload |
| | </syntaxhighlight> |
|
| |
|
| Unter Debian (es sei denn, Sie kompilieren aus dem Quellcode) läuft xrdp als Benutzer <tt>xrdp</tt>.
| | * Schaffung einer Abhängigkeit des Hauptdienstes vom Hilfsdienst: |
| | <syntaxhighlight lang="bash" highlight="1" copy line> |
| | sudo systemctl edit xrdp |
| | </syntaxhighlight> |
|
| |
|
| 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.
| | * Inhalt der Datei: |
| | <syntaxhighlight lang="ini" highlight="" copy line> |
| | [Unit] |
| | After=wait-enp8s0.service |
| | Requires=wait-enp8s0.service |
| | </syntaxhighlight> |
|
| |
|
| Was erhalten Sie für <tt>ls -l /etc/xrdp/key.pem /etc/xrdp/cert.pem</tt>?
| | * Neustart des Dienstes |
| | <syntaxhighlight lang="bash" highlight="1" copy line> |
| | sudo systemctl daemon-reload |
| | </syntaxhighlight> |
|
| |
|
| 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.
| | == Installation == |
| | <syntaxhighlight lang="bash" highlight="1" line copy> |
| | </syntaxhighlight> |
|
| |
|
| === greped kommentierte am 30. Juni 2022 === | | == Aufruf == |
| @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
| | <syntaxhighlight lang="bash" highlight="1" line copy> |
| | </syntaxhighlight> |
|
| |
|
| Meiner Meinung nach sollte ich „<tt>$ chmod 644 /etc/xrdp/cert.pem</tt>” und „<tt>$ chmod 640 /etc/xrdp/key.pem</tt>” ausprobieren, richtig?
| | === Optionen === |
| | {| class="wikitable sortable options gnu big" |
| | |- |
| | ! Unix !! GNU !! Parameter !! Beschreibung |
| | |- |
| | | || || || |
| | |- |
| | |} |
|
| |
|
| === metalefty kommentierte am 1. Juli 2022 === | | === Parameter === |
| Zusätzlich dazu
| | === Umgebungsvariablen === |
| chown :xrdp /etc/xrdp/key.pem
| | === Exit-Status === |
| | {| class="wikitable options col1center big" |
| | |- |
| | ! Wert !! Beschreibung |
| | |- |
| | | 0 || Erfolg |
| | |- |
| | | >0 || Fehler |
| | |} |
|
| |
|
| | == Anwendung == |
| | <syntaxhighlight lang="bash" highlight="1" line copy> |
| | </syntaxhighlight> |
|
| |
|
| === matt335672 kommentierte am 1. Juli 2022 === | | <!-- output --> |
| Das Zertifikat ist in Ordnung. Es ist für alle lesbar, wie es sein sollte, da es keine Geheimnisse enthält.
| | <syntaxhighlight lang="bash" highlight="" line> |
| | </syntaxhighlight> |
|
| |
|
| 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:
| | === Problembehebung === |
| -rw-r----- 1 root xrdp 1704 Jun 26 22:55 /etc/xrdp/key.pem
| |
|
| |
|
| Ist das verständlich?
| | == Konfiguration == |
| | === Dateien === |
| | {| class="wikitable options big" |
| | |- |
| | ! Datei !! Beschreibung |
| | |- |
| | | || |
| | |- |
| | | || |
| | |} |
|
| |
|
| === matt335672 kommentierte am 11. August 2022 ===
| | <noinclude> |
| Keine weiteren Beiträge – schließe.
| |
|
| |
|
| === AvabAlexander kommentierte am 31. August 2022 === | | == Anhang == |
| 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:
| | === Siehe auch === |
| | <div style="column-count:2"> |
| | <categorytree hideroot=on mode="pages">{{BASEPAGENAME}}</categorytree> |
| | </div> |
| | ---- |
| | {{Special:PrefixIndex/{{BASEPAGENAME}}/}} |
|
| |
|
| <tt>chmod 644 /etc/xrdp/cert.pemchmod 640 /etc/xrdp/key.pemchown :xrdp /etc/xrdp/key.pem</tt> | | === Dokumentation === |
| | <!-- |
| | ; Man-Page |
| | # [https://manpages.debian.org/stable/procps/pgrep.1.de.html prep(1)] |
|
| |
|
| === eliassal kommentierte am 12. November 2023 ===
| | ; Info-Pages |
| 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 === | | === Links === |
| 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.
| | ==== Projekt ==== |
| https://salsa.debian.org/debian-remote-team/xrdp/-/blob/debian/0.9.21.1-1/debian/README.Debian?ref_type=tags
| | ==== Weblinks ==== |
|
| |
|
| === 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.
| | {{DEFAULTSORT:new}} |
| | {{DISPLAYTITLE:new}} |
| | --> |
|
| |
|
| === metalefty kommentierte am 13. November 2023 ===
| | [[Kategorie:new]] |
| 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.
| | </noinclude> |
| | |
| === 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 === | | === Weblinks === |
| Zeile 149: |
Zeile 159: |
| # https://pastebin.com/Su2igSwn | | # https://pastebin.com/Su2igSwn |
|
| |
|
| [[Kategorie:XRDP]] | | [[Kategorie:xrdp]] |