xrdp antwortet nicht mehr

[Redoute]

Hallo,

ich habe einen neuen PC mit Debian/KDE Plasma installiert und versuche mich darin einzuarbeiten. Der Rechner soll über RDP bedient werden, dafür habe ich xrdp installiert. Das hat gestern leidlich funktioniert, und ich wollte mich um kleinere Ungereimtheiten kümmern.

Aber heute versuche ich es seit Stunden vergeblich: "Remotedesktop kann [...] keine Verbindung herstellen." Reboot habe ich versucht. In /var/log/xrdp.log und /var/log/xrdp-sesman.log stehen keine Fehlermeldungen, lt. ss ist xrdp am lauschen:

Code: Alles auswählen

tcp      LISTEN    0         2                                       [::1]:3350                  [::]:*        users:(("xrdp-sesman",pid=1945,fd=11))
tcp      LISTEN    0         2                                           *:3389                     *:*        users:(("xrdp",pid=1955,fd=11))

Gibt es hier ein Problem, wieso startet xdrp zweimal?

Code: Alles auswählen

root@fdsserver:~# systemctl status xrdp
● xrdp.service - xrdp daemon
     Loaded: loaded (/lib/systemd/system/xrdp.service; enabled; preset: enabled)
     Active: active (running) since Sun 2023-06-25 11:59:42 CEST; 57min ago
       Docs: man:xrdp(8)
             man:xrdp.ini(5)
    Process: 1946 ExecStartPre=/bin/sh /usr/share/xrdp/socksetup (code=exited, status=0/SUCCESS)
    Process: 1954 ExecStart=/usr/sbin/xrdp $XRDP_OPTIONS (code=exited, status=0/SUCCESS)
   Main PID: 1955 (xrdp)
      Tasks: 1 (limit: 38120)
     Memory: 880.0K
        CPU: 29ms
     CGroup: /system.slice/xrdp.service
             └─1955 /usr/sbin/xrdp

Jun 25 11:59:41 fdsserver systemd[1]: Starting xrdp.service - xrdp daemon...
Jun 25 11:59:41 fdsserver xrdp[1954]: [INFO ] address [0.0.0.0] port [3389] mode 1
Jun 25 11:59:41 fdsserver xrdp[1954]: [INFO ] listening to port 3389 on 0.0.0.0
Jun 25 11:59:41 fdsserver xrdp[1954]: [INFO ] xrdp_listen_pp done
Jun 25 11:59:41 fdsserver systemd[1]: xrdp.service: Can't open PID file /run/xrdp/xrdp.pid (yet?) after start: Operation not permitted
Jun 25 11:59:42 fdsserver systemd[1]: Started xrdp.service - xrdp daemon.
Jun 25 11:59:43 fdsserver xrdp[1955]: [INFO ] starting xrdp with pid 1955
Jun 25 11:59:43 fdsserver xrdp[1955]: [INFO ] address [0.0.0.0] port [3389] mode 1
Jun 25 11:59:43 fdsserver xrdp[1955]: [INFO ] listening to port 3389 on 0.0.0.0
Jun 25 11:59:43 fdsserver xrdp[1955]: [INFO ] xrdp_listen_pp done

Wonach kann ich noch gucken?
Danke, Redoute

[VS2FreeUsers]

Hallo,

xrdp nutzt oft unten drunter xvnc um zu laufen. Am besten mal die xrdp config durchforsten. Weitere mögliche Anhaltspunkte:

- (Default) Firewall
- AppArmor

auch kannst du mal journalctl befragen. Manchmal ist der Fehler übergreifend.

[mat6937]

Aber heute versuche ich es seit Stunden vergeblich: "Remotedesktop kann [...] keine Verbindung herstellen."

Funktioniert der Portscan, auf den TCP-Port 3389?

[Redoute]

Bin heute erst wieder physisch an den Rechner gekommen und habe festgestellt, dass es an einer VM hängt, die ich mit virt-manager eingerichtet habe. Wenn die VM läuft, ist kein Zugriff auf xrdp möglich. Die VM verwendet das Default-Netzwerk von virt-manager (virbr0, NAT in 192.168.122.0/24).

@mat6937: Gilt ein psping fdsserver:3389 als Portscan? -> Zeitüberschreitung.

[mat6937]

@mat6937: Gilt ein psping fdsserver:3389 als Portscan? -> Zeitüberschreitung.

Wenn Du damit einen TCP-Ping gemacht hast, ja. Statt fdsserver kannst Du auch die IP-Adresse benutzen, denn evtl. funktioniert die Namensauflösung für fdsserver nicht (richtig).

[VS2FreeUsers]

Hi,

bei NAT wirst du eine Portforward machen müssen oder auf Bridged umstellen müssen.

[Redoute]

Ja, also psping bekommt Antwort, wenn ich die VM stoppe. Dann funktioniert auch RDP wieder. Aber ich verstehe den Zusammenhang nicht (bzw. hatte den Zusammenhang auch nicht vermutet).

NAT und Port-Forwarding müssten doch erst einmal außen vor sein - das sollte doch nur die Erreichbarkeit des Guest (ein Windows 11, loginbereit) betreffen, aber nicht die des Hosts?

Und das virt-manager-Default-Netzwerk steht immer noch auf Autostart, das scheint den RDP-Zugriff nicht zu stören, solange der Guest ausgeschaltet ist.

[VS2FreeUsers]

Hi,

vieleicht startet der Guest auf dem Port und Blockiert ihn dadurch.

[Redoute]

Hm, also ich habe in virt-manager erst einmal alles abgestellt und stelle das Thema hinten an.

Ich kann das System über xrdp nicht neu starten. Wenn ich "Neu starten" anklicke, wird der RDP-Bildschirm schwarz, aber der Rechner bootet nicht. Bei einer neuen RDP-Verbindung nach Abbruch bekomme ich den Login, und dann wieder den schwarzen Bildschirm. Auch am PC selbst kann ich mich dann nicht mehr grafisch einloggen - es geht nach der Passworteingabe nicht weiter. Erst nach einem Reboot über SSH/Konsole geht der KDE-Login wieder.

Lässt sich das ändern?

[Blackbox]

xrdp nutzt oft unten drunter xvnc um zu laufen.

Blödsinn.
Das eine Protokoll hat mit dem anderen genau was gemein?

[VS2FreeUsers]

xrdp nutzt oft unten drunter xvnc um zu laufen.

Blödsinn.
Das eine Protokoll hat mit dem anderen genau was gemein?

Code: Alles auswählen

root@srv27595:~# cat /etc/xrdp/xrdp.ini | grep -i vnc
[Xvnc]
name=Xvnc
lib=libvnc.so

[Blackbox]

Code: Alles auswählen

root@srv27595:~# cat /etc/xrdp/xrdp.ini | grep -i vnc
[Xvnc]
name=Xvnc
lib=libvnc.so

Und was beweist dein Beitrag?
Dass man durch VNC alles Mögliche tunneln kann, ist nun wirklich kein neues Phänomen.
Dieses Konstrukt ist eine historische Hinterlassenschaft, weil RDP (früher) Anmeldedaten in Klartext übertrug.
Heute sollte das nicht mehr nötig.

Die richtige Fragestellung wäre allerdings gewesen, wieso überhaupt RDP?

[VS2FreeUsers]

Code: Alles auswählen

root@srv27595:~# cat /etc/xrdp/xrdp.ini | grep -i vnc
[Xvnc]
name=Xvnc
lib=libvnc.so

Und was beweist dein Beitrag?
Dass man durch VNC alles Mögliche tunneln kann, ist nun wirklich kein neues Phänomen.
Dieses Konstrukt ist eine historische Hinterlassenschaft, weil RDP (früher) Anmeldedaten in Klartext übertrug.
Heute sollte das nicht mehr nötig.

Die richtige Fragestellung wäre allerdings gewesen, wieso überhaupt RDP?

Hallo,

meines Wissens nach verwendet XRDP verschiedene Backends zum Rendern des Bildschirms unter anderem auch Xvnc. Mein Beitrag bedeutet das Xvnc in der Default config von xrdp mit angegeben ist. Es ist also genau anders herum in diesem Fall. VNC wird über RDP getunnelt, Bzw. kann gibt mehrere Möglichkeiten z.B auch noch x11rdp.

XRDP hat aktuell aus meiner Sicht die folgenden Vorteile:

- XRDP unterstützt TLS Verschlüsselung
- RDP (Client) ist auf vielen Endgeräten (leider) schon Vorinstalliert und kann dadurch direkt verwendet werden.
- XRDP ist durch z.B xfreedesktop relativ leicht zu verwenden

HINWEIS: Das ist nur mein Wissenstand, der kann natürlich auch falsch sein.

[Redoute]

Also "Blödsinn" war der Hinweis wohl nicht. In NEWS.Debian lese ich allerdings: "The default setup since version 0.9 is xorgrdp, not x11rdp or VNC." "Use of VNC is discouraged."

Die richtige Fragestellung wäre allerdings gewesen, wieso überhaupt RDP?

Wieso nicht? Ich hänge nicht speziell an RDP, aber das verwenden wir halt bereits mit den Windowsrechnern, und da funktioniert es gut.

Danke, Redoute

[Blackbox]

Ich hänge nicht speziell an RDP, aber das verwenden wir halt bereits mit den Windowsrechnern, und da funktioniert es gut.

Dir geht es also um den kleinsten gemeinsamen Nenner.
Das wäre eine nützliche Information in deinem Eingangsbeitrag gewesen.

[Redoute]

Erst mal habe ich jetzt zwei bis drei ungelöste kleine(?) Probleme beim Versuch, mit xrdp zu arbeiten:

1. Ich möchte den Rechner vollständig grafisch steuern können inkl. Login und Reboot. Das klappt momentan nicht.

1 a) So wie ich das im Moment sehe, steuert xrdp nicht die laufenden Sitzungen des Rechners (zum Beispiel den Loginscreen von SDDM, mit dem ich mich in KDE einloggen könnte), sondern erzeugt eine komplett eigenständige Umgebung (X Server, Loginscreen). Das ist eigentlich nicht das, was ich will.

2. Ich verstehe nicht, wieso mein KVM-Guest - egal was der gerade treibt - xrdp auf den Host stört - bzw. stören kann.

Aber da du xrdp generell in Frage stellst, lasse ich mich gerne beraten. Mein Eindruck im Moment ist, Desktopumgebungen auf Linux Servern bereiten generell Schmerzen und alle verwenden nur die Kommandozeile. Ist das so?

[VS2FreeUsers]

Hallo,

im Serverbereich wird oft die Konsole verwendet.

Graphisch geht aber auch und Variante Nummer 3 wäre da Web. Kommt halt drauf an was du als Client hast und was du genau tun willst. Sich in eine bestehende Graphische Session die lokal gestartet wurde einzuloggen das habe ich auch noch nicht hinbekommen. Generel hast du graphisch z.B die Möglichkeiten

- RDP wie gewählt
- VNC über ssh tunnel
- VNC über vpn
- VNC über noVNC also Web.
- Spice
- x2go

mit KDE könnte es aber eng werden wegen der graphischen Effekte. Hier Leichtgewichte wie z.B xfce die bessere Wahl.

In der Web Variante kannst du z.B Webmin verwenden oder Proxmox das setzt ja auch auf debian auf.

Wenn es dir um die Verwaltung von VEs geht und du einen Linuxclient verwendest wäre Virt-Manager auch eine gute Wahl. Da geht zwar reboot des Hosts nicht. Aber du kannst wunderbar grafisch VEs verwalten.

[Redoute]

Sich in eine bestehende Graphische Session die lokal gestartet wurde einzuloggen das habe ich auch noch nicht hinbekommen.

In eine laufende KDE- oder GNOME-Sitzung kommt man doch relativ leicht herein? GNOME hat die Einstellung für RDP direkt unter Freigabe, Bildschirmfreigabe. Bei KDE ist es Krfb Desktop Sharing, das kann allerdings wohl nur VNC.

Kommt halt drauf an was du als Client hast und was du genau tun willst.

Ich will den Debianrechner "in die Besenkammer stellen" und nur noch Remote von den Windowsrechnern aus drauf zugreifen. So wie ich das von einem Windows Server, einem Router oder NAS her kenne.

Es soll anfangs eingerichtet werden: Dateiablage (SMB-Freigaben), PostgreSQL/PostGIS, und es soll ein Windows 11 wiederum als Remotedesktop zur Verfügung stehen. Datensicherung mittels restic. Weitere Dienste könnten später dazukommen (NextCloud? LDAP? MapServer/QGIS Server?).

Wenn es dir um die Verwaltung von VEs geht und du einen Linuxclient verwendest wäre Virt-Manager auch eine gute Wahl. Da geht zwar reboot des Hosts nicht. Aber du kannst wunderbar grafisch VEs verwalten.

Ja, an virt-manager hatte ich mich ja bereits versucht, damit kam ich auch ganz gut zurecht. Aber das habe ich halt auf dem KDE-Desktop des Debian-Rechners verwendet.

Edit: Webmin/Proxmox ist mir nun völlig neu - gerade mal gegoogelt. Sollte ich mich eingehender damit beschäftigen?

Redoute

[Redoute]

2. Ich verstehe nicht, wieso mein KVM-Guest - egal was der gerade treibt - xrdp auf den Host stört - bzw. stören kann.

So langsam fällt der Groschen. Wie funktioniert das Default-NAT-Netzwerk von qemu/KVM/virt-manager? Mittels iptables-Regeln! Und plötzlich habe ich eine aktivierte Firewall, ohne es zu ahnen.

Und wieder mal ist es maximal verwickelt: Diese Firewall ist iptables^W nftables^W xtables-nft: iptables using nftables kernel api.

Redoute

[VS2FreeUsers]

Hi,

ja NAT wird durch die Firewall gemacht, darauf wäre ich aber auch nicht gekommen. Wenn du aber zuhause ein der Bessenkammer deinen Host hast, kannst du denk ich auch mit Bridged Network arbeiten. Das ist zwar weniger sicher aber meist Ressourcenschonender und Performanter. Sorry das mit Proxmox hatte ich noch nicht gesehen. Es hat halt seinen Scharm da kannst du VEs und den Host per Webinterface verwalten und setzt auf Debian auf. Webmin ist ein bisschen in die Jahre gekommen... Für mich persönlich ist beides nichts ich bin eher consolen heini

[Redoute]

kannst du denk ich auch mit Bridged Network arbeiten.

Ja, auch damit komme ich in winzigen Schritten und großen Kapriolen voran. Da werde ich mich sicher bald wieder melden.

Danke, Redoute