xrdp disconnects immediately after connection from Windows10/Centos to Centos7

This is my xrdp config:

[Globals]
ini_version=1
fork=true
port=3389
use_vsock=false
tcp_nodelay=true
tcp_keepalive=true
security_layer=negotiate
crypt_level=high
certificate=
key_file=
ssl_protocols=TLSv1.2, TLSv1.3
autorun=
allow_channels=true
allow_multimon=true
bitmap_cache=true
bitmap_compression=true
bulk_compression=true
max_bpp=128
use_compression=yes
new_cursors=true
use_fastpath=both
blue=009cb5
grey=dedede
ls_top_window_bg_color=009cb5
ls_width=350
ls_height=430
ls_bg_color=dedede
ls_logo_filename=
ls_logo_x_pos=55
ls_logo_y_pos=50
ls_label_x_pos=30
ls_label_width=65
ls_input_x_pos=110
ls_input_width=210
ls_input_y_pos=220
ls_btn_ok_x_pos=142
ls_btn_ok_y_pos=370
ls_btn_ok_width=85
ls_btn_ok_height=30
ls_btn_cancel_x_pos=237
ls_btn_cancel_y_pos=370
ls_btn_cancel_width=85
ls_btn_cancel_height=30
[Logging]
LogFile=xrdp.log
LogLevel=DEBUG
EnableSyslog=true
SyslogLevel=DEBUG
[Channels]
rdpdr=true
rdpsnd=true
drdynvc=true
cliprdr=true
rail=true
xrdpvr=true
tcutils=true
[Xvnc]
name=Xvnc
lib=libvnc.so
username=ask
password=ask
ip=127.0.0.1
port=-1
[Xorg]
name=Xorg
lib=libxup.so
username=ask
password=ask
ip=127.0.0.1
port=-1
code=20

I am trying to connect with mstsc to this machine (this is after fresh pc restart, noone has logged in):

xrdp disconnects immediately after connection from Windows10/Centos to Centos7

while in this login box, no disconnect happens:

xrdp disconnects immediately after connection from Windows10/Centos to Centos7

after I put there correct login/password, I get black screen first and then mstsc window closes. I tried to connect from KDE remote connection application, but it also failed same way. xrdp.log doesn’t seem to contain anything interesting:

[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: connecting to sesman ip 127.0.0.1 port 3350
[20190606-04:14:36] [INFO ] xrdp_wm_log_msg: sesman connect ok
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: sending login info to session manager, please wait...
[20190606-04:14:36] [DEBUG] return value from xrdp_mm_connect 0
[20190606-04:14:36] [INFO ] xrdp_wm_log_msg: login successful for display 10
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC started connecting
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC connecting to 127.0.0.1 5910
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC tcp connected
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC security level is 2 (1 = none, 2 = standard)
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC password ok
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC sending share flag
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC receiving server init
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC receiving pixel format
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC receiving name length
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC receiving name
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC sending pixel format
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC sending encodings
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC sending framebuffer update request
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC sending cursor
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC connection complete, connected ok
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: connected ok
[20190606-04:14:36] [DEBUG] xrdp_mm_connect_chansrv: chansrv connect successful
[20190606-04:14:36] [DEBUG] Closed socket 18 (AF_INET 127.0.0.1:47744)
[20190606-04:14:37] [DEBUG] Closed socket 20 (AF_UNIX)
[20190606-04:14:37] [DEBUG] Closed socket 12 (AF_INET 127.0.0.1:3389)
[20190606-04:14:37] [DEBUG] xrdp_mm_module_cleanup
[20190606-04:14:37] [DEBUG] VNC mod_exit
[20190606-04:14:37] [DEBUG] Closed socket 19 (AF_INET 127.0.0.1:40224)

How can I fix that?

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

Try this:

Stop xrdp with
sudo service xrdp stop

Edit the xrdp start script:
sudo nano /etc/xrdp/startwm.sh

In this file, replace the lines

test -x /etc/X11/Xsession && exec /etc/X11/Xsession
exec /bin/sh /etc/X11/Xsession

with
startxfce4

(You can comment out lines by adding # at the start)

Restart xrdp with
sudo service xrdp start

Select Xrdp as the session, and log in.

Method 2

I solved the issue myself, hopefully someone else will find it usefull. I took a look at ~/.xsession-errors, it contained:

(imsettings-check:16467): IMSettings-WARNING **: 04:42:56.491: Could not connect: Connection refused

(imsettings-check:16467): GLib-GIO-CRITICAL **: 04:42:56.491: g_dbus_proxy_call_sync_internal: assertion 'G_IS_DBUS_PROXY (proxy)' failed
GLib-GIO-Message: 04:42:56.807: Using the 'memory' GSettings backend.  Your settings will not be saved or shared with other applications.

** (process:16260): WARNING **: 04:42:56.824: Could not make bus activated clients aware of XDG_CURRENT_DESKTOP=GNOME environment variable: Could not connect: Connection refused

and then I’ve googled a rootcause, miniconda installation has broken PATH in .bashrc file, I have removed this line and it has fixed it:
    export PATH="/home/stiv/miniconda3/bin:$PATH"

UPDATE: Later I’ve found x2go, which works way more reliable and faster then XRDP.

Method 3

  1. sudo apt-get update
  2. sudo apt install xrdp
  3. sudo apt-get install xserver-xorg-core
  4. sudo apt-get install xorgxrdp
  5. nano /etc/polkit-1/localauthority.conf.d/02-allow-colord.conf
  6. Copy the polkit below to 02-allow-colord.conf

polkit.addRule(function(action, subject) {
if ((action.id == "org.freedesktop.color-manager.create-device" || action.id == "org.freedesktop.color-manager.create-profile" || action.id == "org.freedesktop.color-manager.delete-device" || action.id == "org.freedesktop.color-manager.delete-profile" || action.id == "org.freedesktop.color-manager.modify-device" || action.id == "org.freedesktop.color-manager.modify-profile") && subject.isInGroup("{group}"))
{
return polkit.Result.YES;
}
});
  1. sudo ufw allow 3389/tcp
  2. sudo /etc/init.d/xrdp restart
  3. sudo systemctl status xrdp
  4. sudo systemctl enable xrdp
  5. Log out of your session.
  6. Try with RDP

Method 4

The user account you are trying this with, are they a member of the sudo or wheel groups? With Kali 2020 edition, any user that is apart of sudo will disconnect immediately, I had to kill all processes of that user ( pkill -u <username> ) and then delete the user account and recreate it. I am still tracking down the exact reason why this is occurring when I have time. But thought I share my experience.

Method 5

You must do following additional actions:

To Configure Xrdp, first add

exec gnome-session

to the end of the configuration file
/etc/xrdp/xrdp.ini

Or use following command to add “exec gnome-session” to the end of the “/etc/xrdp/xrdp.ini” configuration file
sudo bash -c 'echo "exec gnome-session" >> /etc/xrdp/xrdp.ini'

Restart xrdp to load the new configuration
sudo systemctl restart xrdp

Reference:
How to: Install Xrdp (Remote Desktop) on CentOS 8 – (How to: Use Windows to remote control CentOS 8)

Method 6

I came across this issue trying to connect to a work machine running xrdp on red hat enterprise Linux 7. I had installed miniconda and datalad in its base environment in my home folder on the remote machine and that broke windows remote desktop. The solution was surprisingly simple. I uninstalled datalad and reinstalled it in a new environment via SSH. I was then able to reconnect to the machine via windows remote desktop without any issues.

Method 7

I have spent many days over the past few years with the intermittent problems of accessing a Linux server from a Windows 10 PC. Different approaches to Server xrdp.ini modifications appear to straighten out the issue, but non permanently. After failing with fresh RHEL8 and Centos8 installs, all failing with a PC RDP logon, I observed the following common error. After a fail from the PC, the error, observed from a “semi” successful re-logon from the same PC was observable in systemctl status xrdp which presents the litany of the failed items.
However, when observed directly on the server itself using a screen, keyboard and mouse( I have the Dell R430 in next to me), the systemctl status xrdp, appears clean with no problems.
Each fresh logon to RDP, with Xvnc, apparently launches a separate rdp session/process.
The conclusion I have reached is that the problem is focused on the PC and somehow a SSL failure. It is persistent on the PC UNTIL IT IS rebooted.
The server does not require a restart.
Of course, REBOOTING the PC is impractical, but it is repeatedly successful.

Method 8

I troubleshooted this too, and, it seems that just installing the xrdp package on it’s own is not enough, because (1) dependent packages will not get installed, (2) startwm.sh issues. I didn’t arrive at a perfect solution. I notice one of the other answers is using xfce4 which I would like to use to. In the end, I defaulted to something more lightweight, i.e. icewm, i.e.

sudo yum update
sudo yum install xrdp
sudo yum install tigervnc-server
sudo yum install xterm
sudo yum install icewm
sudo vi /usr/libexec/xrdp/startwm.sh

And, effectively, my startwm.sh script has the following at the top, i.e. I’ve circumvented or replaced the default behavior:

#!/bin/bash -xe
/bin/xterm &
exec /bin/icewm


All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

0 0 votes
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments