0

On my server I run a recent installation of Debian testing (Bookworm, 5.16.0-6-amd64), which I upgraded today. After upgrading all packages I can no longer Win-RDP into the box. Sesman connects fine but the UNIX socket times out after a few minutes. Xrdp worked perfectly before the upgrade and firewall cannot be an issue and I have been using a single login.

Here are the two relevant portions in /var/log/xrdp.log:

[20220408-15:13:05] [INFO ] Using default X.509 certificate: /etc/xrdp/cert.pem
[20220408-15:13:05] [INFO ] Using default X.509 key file: /etc/xrdp/key.pem
[20220408-15:13:05] [ERROR] Cannot read private key file /etc/xrdp/key.pem: Permission denied
[20220408-15:13:05] [ERROR] libxrdp_force_read: header read error
[20220408-15:13:05] [ERROR] Processing [ITU-T T.125] Connect-Initial failed
[20220408-15:13:05] [ERROR] [MCS Connection Sequence] receive connection request failed
[20220408-15:13:05] [ERROR] xrdp_sec_incoming: xrdp_mcs_incoming failed
[20220408-15:13:05] [ERROR] xrdp_rdp_incoming: xrdp_sec_incoming failed
[20220408-15:13:05] [ERROR] xrdp_process_main_loop: libxrdp_process_incoming failed
[20220408-15:13:05] [ERROR] xrdp_iso_send: trans_write_copy_s failed
[20220408-15:13:05] [ERROR] Sending [ITU T.125] DisconnectProviderUltimatum failed

[20220408-15:30:39] [INFO ] connecting to sesman ip 127.0.0.1 port 3350
[20220408-15:30:39] [INFO ] xrdp_wm_log_msg: sesman connect ok
[20220408-15:30:39] [INFO ] sesman connect ok
[20220408-15:30:39] [INFO ] sending login info to session manager, please wait...
[20220408-15:30:39] [INFO ] xrdp_wm_log_msg: login successful for display 10
[20220408-15:30:39] [INFO ] login successful for display 10
[20220408-15:30:39] [INFO ] loaded module 'libxup.so' ok, interface size 10296, version 4
[20220408-15:30:39] [INFO ] started connecting
[20220408-15:30:39] [INFO ] lib_mod_connect: connecting via UNIX socket
[20220408-15:34:09] [INFO ] connection problem, giving up
[20220408-15:34:09] [INFO ] some problem

I found a related issue on the Raspberry Pi forum but switching to VNC does not tackle the issue and the other suggestions look unprofessional to me.

Is there a way to drill down on the UNIX socket "some problem"? Any idea what the "Permission denied" error is about? The file permissions are identical on older servers where xrdp works fine. So my guess is there is something else missing.

Any idea?

I also add the systemctl status:

# systemctl status xrdp

● xrdp.service - xrdp daemon
     Loaded: loaded (/lib/systemd/system/xrdp.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2022-04-08 15:42:18 CEST; 1h 13min ago
       Docs: man:xrdp(8)
             man:xrdp.ini(5)
    Process: 774 ExecStartPre=/bin/sh /usr/share/xrdp/socksetup (code=exited, status=0/SUCCESS)
    Process: 789 ExecStart=/usr/sbin/xrdp $XRDP_OPTIONS (code=exited, status=0/SUCCESS)
   Main PID: 805 (xrdp)
      Tasks: 3 (limit: 76942)
     Memory: 13.0M
        CPU: 59ms
     CGroup: /system.slice/xrdp.service
             ├─  805 /usr/sbin/xrdp
             └─67212 /usr/sbin/xrdp

Apr 08 16:55:30 server2 xrdp[67211]: [ERROR] xrdp_rdp_incoming: xrdp_sec_incoming failed
Apr 08 16:55:30 server2 xrdp[67211]: [ERROR] xrdp_process_main_loop: libxrdp_process_incoming failed
Apr 08 16:55:30 server2 xrdp[67211]: [ERROR] xrdp_iso_send: trans_write_copy_s failed
Apr 08 16:55:30 server2 xrdp[67211]: [ERROR] Sending [ITU T.125] DisconnectProviderUltimatum failed
Apr 08 16:55:30 server2 xrdp[67212]: [ERROR] Cannot read private key file /etc/xrdp/key.pem: Permission denied
Apr 08 16:55:30 server2 xrdp[67212]: [WARN ] Received [MS-RDPBCGR] TS_UD_HEADER type 0xc006 is unknown (ignored)
Apr 08 16:55:30 server2 xrdp[67212]: [WARN ] Received [MS-RDPBCGR] TS_UD_HEADER type 0xc00a is unknown (ignored)
Apr 08 16:55:30 server2 xrdp[67212]: [WARN ] Received [MS-RDPBCGR] TS_UD_HEADER type 0xc008 is unknown (ignored)
Apr 08 16:55:31 server2 xrdp[67212]: [WARN ] xrdp_caps_process_codecs: unknown codec id 5
Apr 08 16:55:31 server2 xrdp[67212]: [WARN ] local keymap file for 0x00000807 found and doesn't match built in keymap, using local keymap file

# systemctl status xrdp-sesman

● xrdp-sesman.service - xrdp session manager
     Loaded: loaded (/lib/systemd/system/xrdp-sesman.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2022-04-08 15:42:17 CEST; 1h 13min ago
       Docs: man:xrdp-sesman(8)
             man:sesman.ini(5)
    Process: 766 ExecStart=/usr/sbin/xrdp-sesman $SESMAN_OPTIONS (code=exited, status=0/SUCCESS)
   Main PID: 771 (xrdp-sesman)
      Tasks: 1 (limit: 76942)
     Memory: 1.8M
        CPU: 72ms
     CGroup: /system.slice/xrdp-sesman.service
             └─771 /usr/sbin/xrdp-sesman

Apr 08 16:55:41 server2 xrdp-sesman[771]: [ERROR] sesman_data_in: scp_process_msg failed
Apr 08 16:55:41 server2 xrdp-sesman[771]: [ERROR] sesman_main_loop: trans_check_wait_objs failed, removing trans

Update:

I tried to purge and reinstall xrdp but I can no longer install xrdp:

# apt install xrdp

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package xrdp is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'xrdp' has no installation candidate

Any suggestions, anyone?

Update II:

I am not sure exactly what the root cause was and I leave the answer open for someone with more Linux-insight.

Here is what I did. Since xrdp was (and still is...) no longer available on Debian:testing I added Debian:unstable to my package list and pinned apt to Debian:testing. This way I could re-install xrdp. But to my disappointment I still could not Win-RDP into the box. That was a week ago.

Today I ran apt update && apt upgrade and rebooted the box and now RDP works fine again! Not sure what exactly fixed the problem. I thought I tried rebooting before as well. So all fine from my end.

sdittmar
  • 363
  • 1
  • 3
  • 15
  • Turns out xrdp was removed from testing and is only available in sid. Seems like I am stuck in no mans land until something is fixed upstream. – sdittmar Apr 10 '22 at 20:46
  • 1
    Don't run pre-releases in production. – vidarlo Apr 23 '22 at 19:40
  • Thank you for the comment - well understood! But it was a valuable **testing** experience for me and it was intentional (no production and only local install). However, next time I would probably pull select packages into stable for a better overall experience. :) – sdittmar Apr 23 '22 at 19:50

0 Answers0