Skip to content

Tips and FAQ

Jump to bottom Edit New page
matt335672 edited this page Sep 23, 2024 · 16 revisions

General

What is RDP?

RDP stands for Remote Desktop Protocol. It's the protocol developed by Microsoft and used in Windows. The protocol specification is open and can be found at Microsoft's site. The most basic part is named [MS-RDPBGCR] (RDP Basic Connectivity and Remoting Graphics). Many other extensions can be found by name prefixed MS-RDP.

What is xrdp?

xrdp, usually spelled in lowercase, is an open-source implementation of the RDP server.

Why can't I log the same user on on the graphical console and over xrdp at the same time?

If you're using a systemd-based distro, you will have noted that if you're logged in on the system graphical console, you can't use the same user to log in over xrdp successfully. Similarly, a user logged in over xrdp will have trouble logging in on the system graphical console.

On systemd-based systems, multiple sessions for the same user share a single instance of the session D-Bus. This allows systemd to support long-lived services for the user, but causes confusion for desktop services which are not expecting to be shared.

This has been raised with systemd - see https://github.com/systemd/systemd/issues/24932, but a possible solution has been rejected.

Issue #2491 is looking into either possible workarounds or enforcing a single session per user on systemd-based systems.

Currently, if your use-case requires the same user to have multiple graphical sessions on one machine you will need to use a distro which does not use systemd.

Why can't I perform some privileged GUI actions?

You may also see prompts to enter a privileged password when using xrdp which you don't see on the machine console.

Most, if not all, Linux desktops use a sub-system called polkit to authorize operations. polkit treats remote users differently from local users, and this is likely the root cause of the differences you are experiencing between local GUI sessions and xrdp sessions.

Linux is used in many different environments, and so some things which are reasonable to do when sat in front of a machine may not be permitted by default when logged in remotely. As an example, consider a non-privileged user. Shutting down the system may be reasonable for this user when sitting in front of the machine, but shouldn't be permitted on a multi-user system by default as this would inconvenience other users. By default, polkit doesn't allow this.

A good description of polkit can be found on the Arch Linux wiki (as with so many other things):-

https://wiki.archlinux.org/title/Polkit

Configuring polkit

To the best of our knowledge no-one has produced an easy-to-use interface to configure polkit. It all needs to be done by the user using text files.

Bear in mind that there are two flavours of polkit in current use:-

Find out which version your distribution uses. The links above contain more information on your version.

Configuring polkit to work over xrdp as if the user was local

This is a commonly requested feature. Before going down this root however, be aware that doing this is dangerous. If an unauthorized user gains access to your machine over xrdp, they will effectively have total access to it.

A test tool has been produced by one of the xrdp developers which generates the required actions to accomplish this.

https://github.com/matt335672/pk-local

This tool is not intended for production environments. By using it in a test environment however, you can work out a subset of the polkit actions you need to configure which are compatible with you use case(s) and your security posture.

Before using the tool, take the trouble to understand what it is doing, and be mindful of the warnings it generates.

Why don't my clipboard and shared drives work when I reconnect?

Here's a detailed description of this problem.

Network

Is it safe to set up xrdp to listen on the Internet?

Short answer; no

Long answer; The RDP protocol has a long history of being hacked by brute force or credential stuffing. You shouldn't expose any kind of RDP server to an unsafe network.

If you want to connect to xrdp over the Internet, consider setting up a VPN. For a small system, Wireguard is a good option. This will allow you to export other services securely as well.

How can I prevent connections being dropped by my corporate firewall?

If you're running through a corporate firewall, you may notice that when you minimise an xrdp session and leave it for some minutes, the connection gets dropped.

The reason for this is that when an xrdp session is minimised, the RDP client asks the server not to send any display updates. This can result in no traffic at all being sent from the xrdp server to the client. Some corporate firewalls will drop connections if they see no traffic.

Connection drops are either explicit (firewall sends a TCP RST to both sides) or silent (firewall drops the connection). Silent connection drops can be bad news, as current versions of xrdp don't realise the client has gone. Consequently they can struggle when the client reconnects - see issue #1188.

There is at present no direct solution within xrdp for this, but there are two workarounds:-

  1. Windows client only. Set HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client\RemoteDesktop_SuppressWhenMinimized to 2 on a Windows client. This will prevent display updates being suppressed. It can however result in a lot more traffic being passed through the corporate firewall.

  2. (Linux xrdp server) Set up a short TCP keepalive. TCP keepalive is a TCP feature which can be used to send a small amount of data on idle TCP connections. The main purpose of this is to detect dead connections. By default, data is not sent until at least 2 hours have elapsed with no data being sent. It is however possible to set this default to a much smaller value. This can prevent corporate firewalls from dropping idle connections.

    Procedure is as follows:-

    1. enable tcp_keepalive in /etc/xrdp/xrdp.ini

    2. restart xrdp

    3. Use these commands to set the system keepalive timer to 5 minutes

      echo 300 | sudo tee /proc/sys/net/ipv4/tcp_keepalive_time   ;# Set keepalive timer to 5 minutes
echo 10 | sudo tee /proc/sys/net/ipv4/tcp_keepalive_intvl   ;# 10 seconds between probes
echo 3 | sudo tee /proc/sys/net/ipv4/tcp_keepalive_probes   ;# 3 probes max

    Despite the names above, these settings apply to both IPv4 and IPv6.

    If 5 minutes is too long a time, change the value which is written to tcp_keepalive_time.

    If this works for you, you may wish to make these values permanent. The best way to do this will vary from system to system. As an example, on Debian/Ubuntu/CentOS/Rocky/AlmaLinux, create a file /etc/sysctl.d/10-tcp-keepalive.conf with the following contents:-

    net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_keepalive_probes = 3

    If your system does not have /etc/sysctl.d/, consult the system documentation for the best way to set kernel variables at system startup time.

Backends

How to choose backend xorgxrdp vs xvnc

Xvnc is the original backend. It supports most features, and is adequate for many use cases. In this mode, xrdp works as a bridge between the RFB(VNC) and RDP protocols. Xorg is an internal Xorg module implemented by xorgxrdp. Because it doesn't need data to be transferred from the Xvnc server over VNC, performance is almost always better, although a few users on high latency WAN links find Xvnc works better. Most new development targets this module first. Using this module does however introduce a dependency on the X server internal interfaces, so system upgrades which change this can occasionally require a new version of xorgxrdp to be provided. [matt335672]

Platforms

Raspberry PI

Why do I get a blue screen when trying to log in to xrdp?

This affects most PI versions using xorgxrdp before v.0.10.2 (i.e. Debian 12, Ubuntu 24.04, Armbian 24.8.1 and earlier).

By default, these platforms have two problems with xrdp:-

  1. The platforms try to use the DRI acceleration built into the kernel for xrdp sessions. Although this acceleration works well on the local console desktop, it turns out it doesn't work at all for remote sessions. To run xrdp on these platforms, you will need to disable DRI acceleration for xrdp sessions. This will not affect your local console at all.
  2. The configuration used by the PI tries to pull the graphics device for the local console into the xrdp configuration.

Both of these can be addressed by editing the file /etc/X11/xrdp/xorg.conf

  1. Find this line:-

    Option "DRMDevice" "/dev/dri/renderD128"

    Comment it out, and replace it with a line with no value:-

    #Option "DRMDevice" "/dev/dri/renderD128"
Option "DRMDevice" ""

  2. Find the section starting with the line `Section "ServerFlags". Addd this line to the end of the section if it isn't already present:-

    Option "AutoAddGPU" "off"

References

Issue Fixed in
1 neutrinolabs/xorgxrdp#322
2 neutrinolabs/xorgxrdp#241

What types of data does clipboard transfer supported?

Clipboard transfer(sharing) supports the following types of data in both directions (server to client, client to server).

  • text
  • image
  • file

How can I restrict outbound clipboard?

Set RestrictOutboundClipboard to true in sesman.ini and restart xrdp-sesman. See also man sesman.ini(5).

How can I restrict clipboard file transfer but allow other clipboard transfers?

It is possible since v0.9.15. Set EnableFuseMount to false in sesman.ini and restart xrdp-sesman. See also man sesman.ini(5).

If EnableFuseMount is set to false, also drive redirection will be disabled at the same time. These cannot be controlled separately.

Add a custom footer
Add a custom sidebar
Clone this wiki locally