Xrdp stuck on login, after password is entered, unblocked if I unlock from the ubuntu rdp server

[chandde]

I'm running Ubuntu 20.04.1. LTS on Hyper-V, also has Xrdp 0.9.12 installed and running on this VM. Here's how I can reproduce this issue,

1. connect to the machine from mstsc
   a. type in username and password on xorg dialog
   b. type in password on ubuntu lock screen
2. wait for ubuntu to lock or directly lock it from xrdp session
3. unlock xrdp, it'll stuck at below screen forever, until, I unlock ubuntu from the hyperv VM.

This happens a lot on multiple VMs, for some reason, the remote unlock is linked to the local unlock. Any idea how I can fix this? is it known?

[matt335672]

Hi @chandde

The unlock functionality in GNOME is different from other desktops - it needs gdm to be running.

Have you got a graphical login on your VM console in Hyper-V?

If not, enable it with sudo systemctl isolate graphical and try again.

You can make the change permanent with sudo systemctl set-default graphical

Can you try that and report back?

[kawa2019]

Hi! @matt335672
thanks for help it really works!

[matt335672]

That's great news.

Can we close this one then?

[kawa2019]

oh It only worked to moment when screensaver start

[matt335672]

I don't quite understand you. Are you saying when the screensaver starts you're unable to unlock the screen?

Can you post a series of events where you see the problem happening?

Thanks.

[jskuo4099]

I've also had the problem.
After the xrdp daemon has been started and I issue a connection request from win10,
I can login the xrdp server successfully.
However, after I have locked the screen of the remote server, which xrdp server runs on, and tried to unlocked it using rdp client,
I failed to do it. It seems that it's ok for the first connection after the xrdp server started, but failed to login after screen lock.
Also, I found another problem: I've to logout the connection when connecting to the xrdp server if I set the fork=true in /etc/xrdp/xrdp.ini, or, I canot login the xrdp server anymore.
remote server: ubuntu 20.04.01 xrdp:0.9.12-1
Would you pls do me a favor giving me some suggestions? thanks!

[matt335672]

Here are the limitations with GNOME 3 as I understand them at the moment:-

1. You can not have the same user logged in to the same machine on more than one graphical session at the same time. So you can't have the same user logged in to Xorg/Xwayland on the console and start an xrdp session. Also you can't have more than one xrdp session running for one user (for example an Xorg session and an Xvnc session).
2. The advice about installing dbus-x11 on the wiki does NOT apply.
3. You must have gdm3 running, as this forms an important part of the screen lock/unlock mechanism:-

   sudo systemctl set-default graphical
   sudo systemctl isolate graphical
   

Try that and let us know how it goes. I can then update the wiki about this.

[jskuo4099]

sorry for replying so late!
I know little about xrdp. What I said below are what I have found in using xrdp.
If I use the default settings of xrdp, i.e., fork=true specified in /etc/xrdp/xrdp.ini
There are multiple sessions listed If I have multiple connections and don' logout the session after I have logined a xrdp session. This will results in some weird problems, such as failed to logon the remote server. It's highly possible because of computational resources exhausted.
However, if I set fork=false in /etc/xrdp/xrdp.ini, I found that the xrdp server can keep the last state as what the MS counterpart does. The problem of failed to logon remote server and unlock screen also disappeared! it seem that this setting is what I want.
The result of sudo systemctl get-default is graphical.target in my box.
hope these observations are useful and thanks for your kind suggestions!

[matt335672]

Having multiple sessions running for the same user will break modern GNOME 3, that's for sure.

I'm not that familiar with the fork=false setting, but I've had a look at what the code does.

The disadvantage of setting fork=false that I can see is that only one person at a time will be able to connect to the box using xrdp. If that's a limitation that you're happy to live with, it's probably the simplest solution for now.

I can give you some other solutions, but bear-in-mind they are relatively complicated. I've listed them below, and you can make up your own mind about that.

The version of XRDP you have (0.9.12) doesn't support resizing on connect with VNC sessions. So if you start a VNC session from one client and then reconnect from a different client at a different resolution, you will get another session.

This can be fixed in one of the following ways:-

• Install a later version of xrdp (at least 0.9.14) to get the resize working properly with the Xvnc backend. You'll need to build xrdp from source to do this I think.
• Install the xorgxrdp package and use the Xorg backend which does support resizing. This will give you other issues to deal with relating to prompts about colour devices - see Auth Window Will not Close - XRDP 0.9.12.1-1 (Win10 to Ubuntu 20.10) #1832 for an example of this. It's the easiest option to try however.
• Use a different desktop. You'll still get multiple sessions, but the unlock will work properly. Other changes are needed to support this.

Let me know if you'd like any more information on any of these.

[jskuo4099]

I'm happy with the setting fork=false for only one person at a time will be able to connect to the box using xrdp so far
and also happy to see that the future xrdp will be more versatile.
The current setting fork=true will result in multiple sessions for the same user and, to me, that's so weird. I wish the future xrdp will keep the last state for the same user as it does for fork=false now.
thanks for your help!

[Gravypan]

I'm still having issues getting xrdp to open correctly. I can remote from Windows 10 to my Ubuntu 20.04 box, but then it connects to a screen with the time and a prompt to Click or press a key to unlock.

And when I do, it prompts me for my password, but then does nothing after I hit enter.

[viertelb]

3. You must have gdm3 running, as this forms an important part of the screen lock/unlock mechanism:-
   ```
   sudo systemctl set-default graphical
   sudo systemctl isolate graphical
   ```

I am trying to log in from a Mac using Microsoft Remote Desktop and have Ubuntu 20.04. running on a Proxmox 7.1 server (on old hardware). The problem is that I cannot login after entering my password sometimes. EDIT: Also, the dock is not shown.

Applying your suggestions resulted in the system going into the shutdown process and hanging there after I entered sudo systemctl isolate graphical.

Stopping the VM and then rebooting and then trying to log in results in a hang after typing in the password.

When I logout from the VNC session that proxmox provides it asks me if it is okay to log out while another user is logged in.

I had made changes to the config to enable multi user but now reverted them.

I also tried the install using the widely known xrdp script some guy provided.

I am happy to set up a new VM and test it if you think it should work.

[matt335672]

The sudo systemctl isolate graphical switches the system immediately into graphical mode. If you do it on a console rather than an ssh session it's possible odd things will happen. In any case, as you've done the sudo systemctl set-default graphical you can just reboot and you should then see gdm3 running on the console.

A hang after typing the password can be down to any number of things, and is nothing to do with the graphical login. You may not have xorgxrdp installed for example. More information is needed to triage that, but if you look for your symptoms elsewhere in the issues you're almost bound to find them. If not, post again.

For the missing dock, see #1915.

[viertelb]

Not sure if I used the word "console" in the right sense. I meant the proxmox console which is a noVNC connection to QEMU (I think. I am not an expert, this is just what it says).

Already had xorgxrdp installed on my Ubuntu 20 client, probably just by installing it as a dependency of xrdp.

---

I did not yet find the reason for the hang in the issues. This is why I will post two screenshots of the logs of xrdp.log and xrdp-sesman.log from a situation where I started the VM freshly, then tried to connect via Microsoft RDP on Mac, which hangs after entering the password. This is until timestamp 19:36.

At 20:23 I am entering the password via the graphical console/display of proxmox, which results in both connections to resolve and show the Ubuntu desktop (I made it possible to be logged in with two connections).

Also, the RDP session is very slow.

Thanks for the link to the missing dock issue, which I was able to resolve.

Apparently, xrdp -v shows 0.9.12. Is this too old? Should I remove the package and install from source?

This is my sesman.ini:

ben@uprox:~$ cat /etc/xrdp/sesman.ini 
;; See `man 5 sesman.ini` for details

[Globals]
ListenAddress=127.0.0.1
ListenPort=3350
EnableUserWindowManager=true
; Give in relative path to user's home directory
UserWindowManager=startwm.sh
; Give in full path or relative path to /etc/xrdp
DefaultWindowManager=startwm.sh
; Give in full path or relative path to /etc/xrdp
ReconnectScript=reconnectwm.sh

[Security]
AllowRootLogin=true
MaxLoginRetry=4
TerminalServerUsers=tsusers
TerminalServerAdmins=tsadmins
; When AlwaysGroupCheck=false access will be permitted
; if the group TerminalServerUsers is not defined.
AlwaysGroupCheck=false
; When RestrictOutboundClipboard=true clipboard from the
; server is not pushed to the client.
RestrictOutboundClipboard=false

[Sessions]
;; X11DisplayOffset - x11 display number offset
; Type: integer
; Default: 10
X11DisplayOffset=10

;; MaxSessions - maximum number of connections to an xrdp server
; Type: integer
; Default: 0
MaxSessions=50

;; KillDisconnected - kill disconnected sessions
; Type: boolean
; Default: false
; if 1, true, or yes, kill session after 60 seconds
KillDisconnected=false

;; DisconnectedTimeLimit - when to kill idle sessions
; Type: integer
; Default: 0
; if not zero, the seconds before a disconnected session is killed
; min 60 seconds
DisconnectedTimeLimit=0

;; IdleTimeLimit (specify in second) - wait before disconnect idle sessions
; Type: integer
; Default: 0
; Set to 0 to disable idle disconnection.
IdleTimeLimit=0

;; Policy - session allocation policy
; Type: enum [ "Default" | "UBD" | "UBI" | "UBC" | "UBDI" | "UBDC" ]
; Default: Xrdp:<User,BitPerPixel> and Xvnc:<User,BitPerPixel,DisplaySize>
; "UBD" session per <User,BitPerPixel,DisplaySize>
; "UBI" session per <User,BitPerPixel,IPAddr>
; "UBC" session per <User,BitPerPixel,Connection>
; "UBDI" session per <User,BitPerPixel,DisplaySize,IPAddr>
; "UBDC" session per <User,BitPerPixel,DisplaySize,Connection>
Policy=Default

[Logging]
LogFile=xrdp-sesman.log
LogLevel=DEBUG
EnableSyslog=1
SyslogLevel=DEBUG

;
; Session definitions - startup command-line parameters for each session type
;

[Xorg]
; Specify the path of non-suid Xorg executable. It might differ depending
; on your distribution and version. The typical path is shown as follows:
;
; Fedora 26 or later    :  param=/usr/libexec/Xorg
; Debian 9 or later     :  param=/usr/lib/xorg/Xorg
; Ubuntu 16.04 or later :  param=/usr/lib/xorg/Xorg
; Arch Linux            :  param=/usr/lib/xorg-server/Xorg
; CentOS 7              :  param=/usr/bin/Xorg or param=Xorg
;
param=/usr/lib/xorg/Xorg
; Leave the rest paramaters as-is unless you understand what will happen.
param=-config
param=xrdp/xorg.conf
param=-noreset
param=-nolisten
param=tcp
param=-logfile
param=.xorgxrdp.%s.log

[Xvnc]
param=Xvnc
param=-bs
param=-nolisten
param=tcp
param=-localhost
param=-dpi
param=96

[Chansrv]
; drive redirection, defaults to xrdp_client if not set
FuseMountName=thinclient_drives
; this value allows only the user to acess their own mapped drives.
; Make this more permissive (e.g. 022) if required.
FileUmask=077

[SessionVariables]
PULSE_SCRIPT=/etc/xrdp/pulse/default.pa

This is my xrdp.ini

ben@uprox:~$ cat /etc/xrdp/xrdp.ini
[Globals]
; xrdp.ini file version number
ini_version=1

; fork a new process for each incoming connection
fork=true

; ports to listen on, number alone means listen on all interfaces
; 0.0.0.0 or :: if ipv6 is configured
; space between multiple occurrences
;
; Examples:
;   port=3389
;   port=unix://./tmp/xrdp.socket
;   port=tcp://.:3389                           127.0.0.1:3389
;   port=tcp://:3389                            *:3389
;   port=tcp://<any ipv4 format addr>:3389      192.168.1.1:3389
;   port=tcp6://.:3389                          ::1:3389
;   port=tcp6://:3389                           *:3389
;   port=tcp6://{<any ipv6 format addr>}:3389   {FC00:0:0:0:0:0:0:1}:3389
;   port=vsock://<cid>:<port>
port=3389

; 'port' above should be connected to with vsock instead of tcp
; use this only with number alone in port above
; prefer use vsock://<cid>:<port> above
use_vsock=false

; regulate if the listening socket use socket option tcp_nodelay
; no buffering will be performed in the TCP stack
tcp_nodelay=true

; regulate if the listening socket use socket option keepalive
; if the network connection disappear without close messages the connection will be closed
tcp_keepalive=true

; set tcp send/recv buffer (for experts)
#tcp_send_buffer_bytes=32768
#tcp_recv_buffer_bytes=32768

; security layer can be 'tls', 'rdp' or 'negotiate'
; for client compatible layer
security_layer=negotiate

; minimum security level allowed for client for classic RDP encryption
; use tls_ciphers to configure TLS encryption
; can be 'none', 'low', 'medium', 'high', 'fips'
crypt_level=high

; X.509 certificate and private key
; openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 365
; note this needs the user xrdp to be a member of the ssl-cert group, do with e.g.
;$ sudo adduser xrdp ssl-cert
certificate=
key_file=

; set SSL protocols
; can be comma separated list of 'SSLv3', 'TLSv1', 'TLSv1.1', 'TLSv1.2', 'TLSv1.3'
ssl_protocols=TLSv1.2, TLSv1.3
; set TLS cipher suites
#tls_ciphers=HIGH

; Section name to use for automatic login if the client sends username
; and password. If empty, the domain name sent by the client is used.
; If empty and no domain name is given, the first suitable section in
; this file will be used.
autorun=

allow_channels=true
allow_multimon=true
bitmap_cache=true
bitmap_compression=true
bulk_compression=true
#hidelogwindow=true
max_bpp=32
new_cursors=true
; fastpath - can be 'input', 'output', 'both', 'none'
use_fastpath=both
; when true, userid/password *must* be passed on cmd line
#require_credentials=true
; You can set the PAM error text in a gateway setup (MAX 256 chars)
#pamerrortxt=change your password according to policy at http://url

;
; colors used by windows in RGB format
;
blue=009cb5
grey=dedede
#black=000000
#dark_grey=808080
#blue=08246b
#dark_blue=08246b
#white=ffffff
#red=ff0000
#green=00ff00
#background=626c72

;
; configure login screen
;

; Login Screen Window Title
#ls_title=My Login Title

; top level window background color in RGB format
ls_top_window_bg_color=009cb5

; width and height of login screen
ls_width=350
ls_height=430

; login screen background color in RGB format
ls_bg_color=dedede

; optional background image filename (bmp format).
#ls_background_image=

; logo
; full path to bmp-file or file in shared folder
ls_logo_filename=
ls_logo_x_pos=55
ls_logo_y_pos=50

; for positioning labels such as username, password etc
ls_label_x_pos=30
ls_label_width=65

; for positioning text and combo boxes next to above labels
ls_input_x_pos=110
ls_input_width=210

; y pos for first label and combo box
ls_input_y_pos=220

; OK button
ls_btn_ok_x_pos=142
ls_btn_ok_y_pos=370
ls_btn_ok_width=85
ls_btn_ok_height=30

; Cancel button
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
; LogLevel and SysLogLevel could by any of: core, error, warning, info or debug

[Channels]
; Channel names not listed here will be blocked by XRDP.
; You can block any channel by setting its value to false.
; IMPORTANT! All channels are not supported in all use
; cases even if you set all values to true.
; You can override these settings on each session type
; These settings are only used if allow_channels=true
rdpdr=true
rdpsnd=true
drdynvc=true
cliprdr=true
rail=true
xrdpvr=true
tcutils=true

; for debugging xrdp, in section xrdp1, change port=-1 to this:
#port=/tmp/.xrdp/xrdp_display_10

; for debugging xrdp, add following line to section xrdp1
#chansrvport=/tmp/.xrdp/xrdp_chansrv_socket_7210


;
; Session types
;

; Some session types such as Xorg, X11rdp and Xvnc start a display server.
; Startup command-line parameters for the display server are configured
; in sesman.ini. See and configure also sesman.ini.
[Xorg]
name=Xorg
lib=libxup.so
username=ask
password=ask
ip=127.0.0.1
port=-1
code=20

[Xvnc]
name=Xvnc
lib=libvnc.so
username=ask
password=ask
ip=127.0.0.1
port=-1
#xserverbpp=24
#delay_ms=2000

[vnc-any]
name=vnc-any
lib=libvnc.so
ip=ask
port=ask5900
username=na
password=ask
#pamusername=asksame
#pampassword=asksame
#pamsessionmng=127.0.0.1
#delay_ms=2000

[neutrinordp-any]
name=neutrinordp-any
lib=libxrdpneutrinordp.so
ip=ask
port=ask3389
username=ask
password=ask

; You can override the common channel settings for each session type
#channel.rdpdr=true
#channel.rdpsnd=true
#channel.drdynvc=true
#channel.cliprdr=true
#channel.rail=true
#channel.xrdpvr=true

session manager:

ben@uprox:~$ sudo update-alternatives --query x-session-manager
[sudo] Passwort für ben: 
Name: x-session-manager
Link: /usr/bin/x-session-manager
Slaves:
 x-session-manager.1.gz /usr/share/man/man1/x-session-manager.1.gz
Status: auto
Best: /usr/bin/gnome-session
Value: /usr/bin/gnome-session

Alternative: /usr/bin/gnome-session
Priority: 50
Slaves:
 x-session-manager.1.gz /usr/share/man/man1/gnome-session.1.gz

Just for information, I am running High Sierra on an old iMac. But my RDP connections work very well to other machines.

[matt335672]

I can't see any problems with those log files. The xrdp.log shows the connection happening immediately. The request comes in at 20:23:59, and the actual connect is done by 20:24:00

So it's more likely your actual session is hanging for some reason.

With modern Linux systems using systemctl --user, you can only have one graphical session at a time for any one user, although you can have any number of terminal sessions. A graphical session will be an xrdp login, or a login on the system console. Is that likely to be an issue here?

[viertelb]

Thank you very much!

Yes, when I deactivate the display in the console of proxmox RDP works. I did test this before but had issues with it. Now I cannot reproduce them. I can shutdown and restart and suspend and put in my password after suspension and it it works.

But when I shutdown or suspend I have to put in my password to actually shutdown. I don't have to do this over the proxmox console.

Do you also happen to have a resolution for this?

[matt335672]

The password is related to a program called polkit.

Because xrdp is a remote session it doesn't have privilege to do many things you can do from the console by default. For example, rebooting a system is fine if it's your own personal system, but not fine at all if you are sharing a server with ten other people.

You can configure the system not to ask for a password. The first thing to do is identify the policy kit action, and the second is to create a .pkla file to allow the action to succeed.

To find the action, the simplest thing is to cancel the password prompt and then look in /var/log/auth.log. On my ubuntu system, if I try to shut down over xrdp and cancel, I get this in the log:-

Apr  7 13:49:08 xrdp-test polkitd(authority=local): Operator of unix-session:c5 FAILED to authenticate to gain authorization for action org.freedesktop.login1.power-off-multiple-sessions for system-bus-name::1.234 [/usr/libexec/gnome-session-binary --systemd-service --session=ubuntu] (owned by unix-user:testuser)

The policy kit action org.freedesktop.login1.power-off-multiple-sessions looks like this:-

$ pkaction  --verbose --action-id org.freedesktop.login1.power-off-multiple-sessions
org.freedesktop.login1.power-off-multiple-sessions:
  description:       Power off the system while other users are logged in
  message:           Authentication is required to power off the system while other users are logged in.
  vendor:            The systemd Project
  vendor_url:        http://www.freedesktop.org/wiki/Software/systemd
  icon:              
  implicit any:      auth_admin_keep
  implicit inactive: auth_admin_keep
  implicit active:   yes
  annotation:        org.freedesktop.policykit.imply -> org.freedesktop.login1.power-off

For RDP, implicit any is the relevant setting. auth_admin_keep means you need to authenticate, or need to have authenticated very recently.

Creation of a pkla file is left to you - it's a good way to learn about polkit. #1568 has some useful information in it.

[donatelos1957]

Thank you very much!

Yes, when I deactivate the display in the console of proxmox RDP works. I did test this before but had issues with it. Now I cannot reproduce them. I can shutdown and restart and suspend and put in my password after suspension and it it works.

But when I shutdown or suspend I have to put in my password to actually shutdown. I don't have to do this over the proxmox console.

Do you also happen to have a resolution for this?

Hi, if I got it right, it's impossible to work simultaneously with one user on different graphical sessions, e.g., server direct screen and RDP sessions. Actually, it works perfectly before the first screen lock, but after, you can't type a password (just no reaction after pressing Enter). I resolved this by turning off autologin mode at the main Ubuntu machine, so after rebooting it is not autologged and I'm able to use my user session through RDP even after screen lock. I hope it will help someone. If anybody knows how to use one user in different graphical sessions, I would appreciate the advices.

[matt335672]

I added this to the FAQ recently:-

https://github.com/neutrinolabs/xrdp/wiki/Tips-and-FAQ#why-cant-i-log-the-same-user-on-on-the-graphical-console-and-over-xrdp-at-the-same-time

It's a particular problem for GNOME, as the lock screen is implemented by GDM.

[Sinan81]

At my company, we had an issue with screen lock being, sometimes not responsive to keyboard events upon xrdp login. I figured, that one can unlock from command line via loginctl like:

loginctl list-sessions
loginctl unlock-session cX

where X is an integer. cX is a session associated with the user running the above command.