[gelöst] xrdp und Remmina (Debian 11 bullseye)

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
Antworten
buhtz
Beiträge: 1105
Registriert: 04.12.2015 17:54:49
Kontaktdaten:

[gelöst] xrdp und Remmina (Debian 11 bullseye)

Beitrag von buhtz » 24.08.2021 11:06:25

Ich versuche xrdp mit Remmina als Client zu nutzen.
Im Grunde dreht sich meine Frage hier darum, wie ich an ordentliche Fehlermeldungen komme, um weiter recherchieren zu können.

Beide Rechner sind im lokalen Netzwerk. Der Server ist per ssh key (also ohne Passwort-Eingabe) mit ssh-shell erreichbar.

Remmina überfordert mich etwas mit den Einstellungsmöglichkeiten und gibt gleichzeitig keine verwertbaren Auskünfte über die Fehlerursache. Es gibt zwei Varianten.

Remmina bietet eine Art Adresszeile im Hauptfenster an. Dort wähle ich "RDP" aus dem drop-down menu und gebe dann den Servernamen probiert an.
Ein zweites Fenster geht auf und dort steht nur "Wiederherstellen der Verbindung. Versuch 1 von". Bei user@server sagt er, dass er die Adresse nicht finden kann. Gehe daher davon aus, dass man hier keinen Usernamen angeben darf.
Auf der Serverseite sieht das dann so aus:

Code: Alles auswählen

sudo systemctl status xrdp -f
● xrdp.service - xrdp daemon
     Loaded: loaded (/lib/systemd/system/xrdp.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2021-08-24 10:48:46 CEST; 9min ago
       Docs: man:xrdp(8)
             man:xrdp.ini(5)
    Process: 11743 ExecStartPre=/bin/sh /usr/share/xrdp/socksetup (code=exited, status=0/SUCCESS)
    Process: 11751 ExecStart=/usr/sbin/xrdp $XRDP_OPTIONS (code=exited, status=0/SUCCESS)
   Main PID: 11752 (xrdp)
      Tasks: 2 (limit: 9356)
     Memory: 11.5M
        CPU: 6.833s
     CGroup: /system.slice/xrdp.service
             ├─11752 /usr/sbin/xrdp
             └─14274 /usr/sbin/xrdp

Aug 24 10:58:43 TONNE xrdp[14274]: (14274)(140297243027264)[DEBUG] TLSv1.3 enabled
Aug 24 10:58:43 TONNE xrdp[14274]: (14274)(140297243027264)[DEBUG] TLSv1.2 enabled
Aug 24 10:58:43 TONNE xrdp[14274]: (14274)(140297243027264)[DEBUG] Security layer: requested 3, selected 0
Aug 24 10:58:43 TONNE xrdp[14274]: (14274)(140297243027264)[INFO ] connected client computer name: SNIPPED
Aug 24 10:58:43 TONNE xrdp[14274]: (14274)(140297243027264)[INFO ] adding channel item name cliprdr chan_id 1004 flags 0xc0a00000
Aug 24 10:58:43 TONNE xrdp[14274]: (14274)(140297243027264)[INFO ] adding channel item name drdynvc chan_id 1005 flags 0xc0800000
Aug 24 10:58:43 TONNE xrdp[14274]: (14274)(140297243027264)[INFO ] Non-TLS connection established from ::ffff:192.168.178.20 port 53108: encrypted with standard RDP security
Aug 24 10:58:43 TONNE xrdp[14274]: (14274)(140297243027264)[DEBUG] xrdp_000037c2_wm_login_mode_event_00000001
Aug 24 10:58:43 TONNE xrdp[14274]: (14274)(140297243027264)[INFO ] Loading keymap file /etc/xrdp/km-00000407.ini
Aug 24 10:58:43 TONNE xrdp[14274]: (14274)(140297243027264)[WARN ] local keymap file for 0x00000407 found and doesn't match built in keymap, using local keymap file
OK, dann habe ich versucht eine "entfernte Arbeitsfläche" (die Liste darunter) fest zu konfigurieren und hier diverse Einstellungen durchprobiert.
Protokoll "RDP", "Server" und "Benuztername" gesetzt. Passwort habe ich leer gelassen, a) weil ich es nicht gespeichert haben will und ggf. jedes Mal selbst eingeben würde b) weil ich wegen dem ssh-key ja eigentlich kein Passwort benötigen müsste. Unter "Erweitert" findet sich "Sicherheit" (default: "Verhandeln") und "Gateway Transport Typ" (default: "http"). Defaults hatte ich belassen, aber auch mal mit Sicherheit=RDP und GatwayTransportTyp=auto probiert. Im Reiter SSH-Tunnel habe ich "aktivieren" aktiviert. :D SS-Authentifizierung auf "öffentlicher Schüssel (automatisch)" gesetzt. "Tunnel über loopback-Adresse" habe ich wahlweise (de)aktiviert. Unverändert.
Bei dieser Verbindungsform scheint kurz (<1sec) ein Fenster aufzugehen und ein Desktop mit einem (grauen/leeren) Fenster darauf aufzugehen.

Sieht auf dem Server so aus:

Code: Alles auswählen

sudo systemctl status xrdp -f
● xrdp.service - xrdp daemon
     Loaded: loaded (/lib/systemd/system/xrdp.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2021-08-24 10:48:46 CEST; 7min ago
       Docs: man:xrdp(8)
             man:xrdp.ini(5)
    Process: 11743 ExecStartPre=/bin/sh /usr/share/xrdp/socksetup (code=exited, status=0/SUCCESS)
    Process: 11751 ExecStart=/usr/sbin/xrdp $XRDP_OPTIONS (code=exited, status=0/SUCCESS)
   Main PID: 11752 (xrdp)
      Tasks: 1 (limit: 9356)
     Memory: 1.1M
        CPU: 6.578s
     CGroup: /system.slice/xrdp.service
             └─11752 /usr/sbin/xrdp

Aug 24 10:56:14 TONNE xrdp[14193]: (14193)(140297243027264)[DEBUG] Security layer: requested 3, selected 0
Aug 24 10:56:14 TONNE xrdp[14193]: (14193)(140297243027264)[INFO ] connected client computer name: SNIPPED
Aug 24 10:56:14 TONNE xrdp[14193]: (14193)(140297243027264)[INFO ] adding channel item name cliprdr chan_id 1004 flags 0xc0a00000
Aug 24 10:56:14 TONNE xrdp[14193]: (14193)(140297243027264)[INFO ] adding channel item name drdynvc chan_id 1005 flags 0xc0800000
Aug 24 10:56:14 TONNE xrdp[14193]: (14193)(140297243027264)[INFO ] Non-TLS connection established from ::ffff:127.0.0.1 port 51302: encrypted with standard RDP security
Aug 24 10:56:15 TONNE xrdp[14193]: (14193)(140297243027264)[DEBUG] xrdp_00003771_wm_login_mode_event_00000001
Aug 24 10:56:15 TONNE xrdp[14193]: (14193)(140297243027264)[INFO ] Loading keymap file /etc/xrdp/km-00000407.ini
Aug 24 10:56:15 TONNE xrdp[14193]: (14193)(140297243027264)[WARN ] local keymap file for 0x00000407 found and doesn't match built in keymap, using local keymap file
Aug 24 10:56:15 TONNE xrdp[14193]: (14193)(140297243027264)[DEBUG] Closed socket 12 (AF_INET6 ::ffff:127.0.1.1 port 3389)
Aug 24 10:56:15 TONNE xrdp[14193]: (14193)(140297243027264)[DEBUG] xrdp_mm_module_cleanup
EDIT: Beim Verbinden fragt er mich immer nach der SSH-Passphrase, obwohl der Schlüssel keine Passphrase hat. Das Feld lasse ich leer.

UPDATE: Ich hatte jetzt auch die Gelegenheit ein Windows10 Rechner als Client zu probieren. Die Windows eigene Remote-Desktop-Verbindung findet den Server per IP und bietet mir dann auch eine Art Desktop-im-Fenster mit einem Login-Screen (so wie hier) an. Dort wähle ich Session=Xorg, sowie Nutzername und Passwort (so wie wenn ich mich lokal am Server anmelden würde). Danach geht der komplette Fenster-Desktop ohne Fehlermeldung einfach zu.

Der Server-Log

Code: Alles auswählen

 sudo systemctl status xrdp
● xrdp.service - xrdp daemon
     Loaded: loaded (/lib/systemd/system/xrdp.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2021-08-24 11:32:56 CEST; 1h 28min ago
       Docs: man:xrdp(8)
             man:xrdp.ini(5)
    Process: 828 ExecStartPre=/bin/sh /usr/share/xrdp/socksetup (code=exited, status=0/SUCCESS)
    Process: 858 ExecStart=/usr/sbin/xrdp $XRDP_OPTIONS (code=exited, status=0/SUCCESS)
   Main PID: 869 (xrdp)
      Tasks: 1 (limit: 9356)
     Memory: 2.4M
        CPU: 362ms
     CGroup: /system.slice/xrdp.service
             └─869 /usr/sbin/xrdp

Aug 24 13:01:20 TONNE xrdp[11365]: (11365)(140615180224320)[INFO ] xrdp_wm_log_msg: login successful for display 10
Aug 24 13:01:20 TONNE xrdp[11365]: (11365)(140615180224320)[DEBUG] xrdp_wm_log_msg: started connecting
Aug 24 13:01:20 TONNE xrdp[11365]: (11365)(140615180224320)[INFO ] lib_mod_log_peer: xrdp_pid=11365 connected to X11rdp_pid=11387 X11rdp_uid=1000 X11rdp_gid=1000 client_ip=::ffff:192.168.178.50 client_port=58358
Aug 24 13:01:20 TONNE xrdp[11365]: (11365)(140615180224320)[DEBUG] xrdp_wm_log_msg: connected ok
Aug 24 13:01:20 TONNE xrdp[11365]: (11365)(140615180224320)[DEBUG] xrdp_mm_connect_chansrv: chansrv connect successful
Aug 24 13:01:20 TONNE xrdp[11365]: (11365)(140615180224320)[DEBUG] Closed socket 16 (AF_INET6 ::1 port 51626)
Aug 24 13:01:20 TONNE xrdp[11365]: (11365)(140615180224320)[DEBUG] Closed socket 12 (AF_INET6 ::ffff:192.168.178.37 port 3389)
Aug 24 13:01:20 TONNE xrdp[11365]: (11365)(140615180224320)[DEBUG] xrdp_mm_module_cleanup
Aug 24 13:01:20 TONNE xrdp[11365]: (11365)(140615180224320)[DEBUG] Closed socket 17 (AF_UNIX)
Aug 24 13:01:20 TONNE xrdp[11365]: (11365)(140615180224320)[DEBUG] Closed socket 18 (AF_UNIX)
Zuletzt geändert von buhtz am 24.08.2021 16:36:41, insgesamt 1-mal geändert.
Debian 11 & 12; Desktop-PC, Headless-NAS, Raspberry Pi 4
Teil des Upstream Betreuer Teams von Back In Time (Debianbackintime)

buhtz
Beiträge: 1105
Registriert: 04.12.2015 17:54:49
Kontaktdaten:

Re: xrdp und Remmina

Beitrag von buhtz » 24.08.2021 16:36:17

Der Workaround kommt hier her
https://serverspace.io/support/help/how ... ntu-18-04/

In der Datei /etc/xrdp/startwm.sh muss vor den letzten zwei Zeilen, das hier eingefügt werden.

Code: Alles auswählen

unset DBUS_SESSION_BUS_ADDRESS
unset XDG_RUNTIME_DIR
Geht.

Hinweis:
Hier wird die selbe X-Session verwendet - wenn man das so ausdrücken darf. So sehr "das Selbe" ist es aber nicht. ;)
Alle Autostarts (z.B. ownCloud, nextCloud, KeepassXC) werden beim remote login neu ausgeführt und ploppen auf dem Server-Bildschirm auf. Läuft Firefox schon auf dem Server, kann ich es auf dem Remote-Client nicht mehr starten, weil es ja schon läuft. Sehen kann ich das laufende Firefox dort aber nicht.
Kurz: Der Remote-Desktop sieht nicht so aus, wie der auf dem Server. Es ist kein klassischer Spiegel-Bildschirm.

Debian-Frage:
Aus meiner Anwender-Sicht, ist das jetzt ein Bug, weil das Paket nicht out of the box läuft und auch keine adäquaten Fehlermeldungen vorhanden waren.
Diese simplen zwei Zeilen müssen da in die Konfig-Datei rein. Warum kann das nicht schon im deb-file so gemacht werden? Wir sind ja hier nicht bei Linux-From-Scratch.
Oder liegt es doch an einer speziellen Eigenheit meines Setups und macht deshalb nicht bei jedem Sinn?
Lohnt es sich hier einen Debian-bugreport aufzumachen, oder kann ich mir die Mühe sparen? ;)

EDIT: Also die Frage nach den Hintergründen dieses evtl. Bugs und was diese zwei Zeilen überhaupt bewirken wäre mir sehr wichtig. Es geht z.B. darum zu entscheiden, ob das Debian-spezifisch ist oder lieber zu Upstream gehört.
Debian 11 & 12; Desktop-PC, Headless-NAS, Raspberry Pi 4
Teil des Upstream Betreuer Teams von Back In Time (Debianbackintime)

Antworten