xrdp on a Linux VPS: Remote Desktop to Ubuntu 24.04 and Debian 13, Tested Step by Step

xrdp is the free server that gives a Linux VPS a full remote desktop you open with ordinary Remote Desktop apps: Remote Desktop Connection (mstsc) on Windows, Windows App on a Mac, Remmina or xfreerdp3 on Linux. On Debian 13 and Ubuntu 24.04 the recipe is short: install the XFCE desktop and xrdp, let xrdp read its TLS key, make each user's session start XFCE, create a normal user, and reach port 3389 through an SSH tunnel instead of opening it to the internet. We ran every server and Linux command below in two test VMs on 12 October 2026, connected from a separate Linux machine, and broke the setup on purpose to collect the errors you are most likely to meet.

Key facts, checked on 13 October 2026:

• The latest xrdp release is 0.10.6.1 from July 2026, which fixes 10 vulnerabilities. The project calls the older 0.9.x series end-of-life (xrdp releases).
• Debian 13 ships xrdp 0.10.1-3.1+deb13u2 (packages.debian.org), patched for 17 CVEs by DSA-6469-1 on 27 August 2026.
• Ubuntu 24.04 ships xrdp 0.9.24-4ubuntu0.1 from its community-maintained universe section. Ubuntu's fix for CVE-2025-68670, a stack overflow an attacker can trigger before logging in (CVSS 9.1), is available only through ESM Apps, part of Ubuntu Pro.
• xrdp listens on TCP port 3389 and encrypts with TLS 1.2 or 1.3 using a self-signed certificate. It does not support Network Level Authentication (NLA), as Microsoft's xrdp guide points out.
• In our lab, each idle XFCE session added 160 to 195 MB of RAM on Debian 13 and 340 to 365 MB on Ubuntu 24.04. Firefox with one page open added about 600 MB more.

How xrdp works, in two minutes

RDP (Remote Desktop Protocol) is Microsoft's way of sending a screen over the network and your keyboard and mouse back; xrdp speaks it on Linux. At login, its session manager, xrdp-sesman, starts a private, invisible screen for you (display :10, then :11 for the next user) and runs your desktop in it. Several people can work at once, and closing the window leaves your programs running: our log said ++ reconnected session: username ana, display :10.0 when we came back. We used XFCE, a light desktop that needs no graphics card.

Step 1: install XFCE and xrdp

Both test VMs had 2 vCPUs and 3 GB of RAM, close to a small VPS. Log in over SSH as root and run:

# as root, on Debian 13 or Ubuntu 24.04
apt-get update
DEBIAN_FRONTEND=noninteractive apt-get install -y xfce4 xfce4-goodies xrdp
systemctl is-active xrdp
ss -ltn | grep 3389

DEBIAN_FRONTEND stops apt from pausing for setup questions such as a keyboard layout; RDP sends your own PC's layout at login anyway. The last two lines should print active and a LISTEN line with *:3389, meaning xrdp listens on every address. The install took 188 seconds and 1,689 MB of disk on Debian 13, and 276 seconds and 1,885 MB on Ubuntu 24.04, downloaded package files included. apt's estimates for three package sets on Debian 13:

The install also brings LightDM, a login screen for a monitor nobody watches on a VPS. Switching it off cut idle memory from 447 to 324 MB on Debian and from 548 to 392 MB on Ubuntu, and it is behind the most common black screen (see the troubleshooting table):

# as root
systemctl disable --now lightdm

Step 2: two fixes Ubuntu 24.04 needs and Debian 13 tolerates

Let xrdp read its TLS key

On Ubuntu, xrdp runs as its own user, xrdp, and the key behind its certificate is readable only by root and the ssl-cert group. Without this fix our client still connected, which is the dangerous part: the log said Cannot read private key file /etc/xrdp/key.pem: Permission denied, then Non-TLS connection established. xrdp had quietly fallen back to the old RDP encryption. On Debian 13 the xrdp process runs as root, which can read the key anyway, so there the command is only a precaution:

# as root
adduser xrdp ssl-cert
systemctl restart xrdp

After the next login, grep "TLS connection" /var/log/xrdp.log showed TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 on both VMs.

Tell the session to start XFCE

xrdp starts the system's default session. On Debian 13 that was XFCE. On Ubuntu 24.04 the install also pulled in gnome-session as a dependency, and it became the default, so our first login showed GNOME's "Oh no! Something has gone wrong." screen. A one-line ~/.xsession file per user fixes it, created in the next step.

Step 3: a desktop user, and root kept out

xrdp checks Linux passwords, not SSH keys. Create the user, then its session file (needed on Ubuntu, harmless on Debian):

# as root
adduser ana
su - ana -c 'echo "startxfce4" > ~/.xsession'

adduser asks for the password twice, then for a name and phone numbers; press Enter through those. Both packages also ship /etc/xrdp/sesman.ini with AllowRootLogin=true, and root got a full desktop in our Debian VM. Turn that off, allow only one group, and refuse the old RDP encryption:

# as root
sed -i 's/^AllowRootLogin=true/AllowRootLogin=false/' /etc/xrdp/sesman.ini
addgroup tsusers
adduser ana tsusers
sed -i 's/^security_layer=negotiate/security_layer=tls/' /etc/xrdp/xrdp.ini
systemctl restart xrdp-sesman xrdp

We ran this on Debian 13; Ubuntu's files have the same settings. The session log then said ROOT login attempted, but root login is disabled for root and User ben is not in TerminalServerUsers group tsusers. Access denied for a second user, and a client forced to the old encryption got Server requires TLS for security, but the client did not request TLS.

Restart xrdp only while nobody is logged in. It restarts xrdp-sesman too, which forgets running desktops: ana's next login opened a second desktop that closed after one second, a black screen. loginctl terminate-user ana clears the old one, along with that user's SSH logins.

Step 4: keep port 3389 off the internet

Anything on port 3389 gets found fast: on a fresh Windows server in our Windows RDP test, the first password guess arrived seven minutes after boot. The Sophos 2026 Active Adversary Report found attackers abusing RDP inside the victim's network in 66% of 661 incidents (November 2024 to October 2025) and using it to get in from outside in 10%. And a strong password doesn't stop a bug like CVE-2025-68670, which strikes before the login screen.

Option 1: an SSH tunnel (what we recommend)

The tunnel carries RDP inside your SSH login, so only SSH's port 22 stays open. Make xrdp listen on the server itself only:

# as root
sed -i 's|^port=3389$|port=tcp://.:3389|' /etc/xrdp/xrdp.ini
systemctl restart xrdp
ss -ltn | grep 3389

The last line should show 127.0.0.1:3389 (it did on both systems), and a direct connection from our client then failed. Open the tunnel from your computer and connect through it:

# on your Linux PC, as your normal user
ssh -f -N -L 13389:localhost:3389 ana@YOUR_SERVER_IP
xfreerdp3 /v:localhost:13389 /u:ana /cert:tofu

-L sends port 13389 on your PC to port 3389 on the server, and -f -N keeps the tunnel in the background without a shell; 13389 avoids clashing with a Remote Desktop server on your own PC. xrdp then logged connection accepted from 127.0.0.1. Any SSH account can carry the tunnel, so if our Debian 13 hardening guide limits SSH to keys, tunnel as your admin user and log in to the desktop as ana.

We tested the tunnel from Linux only. A Mac has the same ssh command in Terminal, and in Windows App you would add a PC called localhost:13389. On Windows 10 (build 1809 or later) and Windows 11, ssh comes with the OpenSSH Client optional feature, per Microsoft's documentation; you would run the same line without -f in PowerShell, keep that window open, and point Remote Desktop Connection at localhost:13389.

Option 2: a private network

With WireGuard or Tailscale, you connect to the server's private VPN address instead. Keep xrdp on all addresses and allow 3389 only on the VPN interface. For a team this is easier than one tunnel each.

Option 3: one allowed IP, and a ban for password guessers

If you must open the port, open it to your own address only:

# as root
apt-get install -y ufw
ufw allow OpenSSH
ufw allow from YOUR_HOME_IP to any port 3389 proto tcp
ufw --force enable
ufw status

--force skips the "may disrupt existing ssh connections" question. In our test the allowed client connected and another address got no answer. Home addresses change, though, and if you already use the nftables policy from our hardening guide, add the rule there instead.

fail2ban 1.1.0 on Debian 13 has no xrdp filter, but xrdp 0.10 logs every wrong password as AUTHFAIL: user=ben ip=::ffff:10.141.188.26. This filter strips the ::ffff: prefix so the plain IPv4 address gets banned:

# as root
apt-get install -y fail2ban
cat > /etc/fail2ban/filter.d/xrdp-sesman.conf <<'EOF'
[Definition]
failregex = AUTHFAIL: user=\S* ip=(?:::ffff:)?<HOST> time=
EOF
cat > /etc/fail2ban/jail.d/xrdp.local <<'EOF'
[xrdp]
enabled  = true
port     = 3389
filter   = xrdp-sesman
logpath  = /var/log/xrdp-sesman.log
backend  = auto
maxretry = 3
findtime = 10m
bantime  = 1h
EOF
systemctl restart fail2ban
fail2ban-client status xrdp

After three wrong passwords, fail2ban logged [xrdp] Ban 10.141.188.26 and the port answered Connection refused; fail2ban-client set xrdp unbanip YOUR_IP undoes it. Tested on Debian 13 only.

Step 5: connect, then confirm the desktop started

On Linux, install the client with apt install freerdp3-x11 and run the xfreerdp3 line above. It asks Domain: (press Enter) and Password:; the first time, /cert:tofu logs No certificate stored, automatically accepting. The desktop was running about 1.3 seconds after xrdp accepted the password. Our Remote Desktop error guide decodes xfreerdp3 and Remmina messages.

We didn't run a Windows client in this lab. Going by Microsoft's xrdp guide, in Remote Desktop Connection you type the address (or localhost:13389), accept the warning about the self-signed certificate, and xrdp's own login window asks for the user name and password; leave its session type on Xorg.

To see the session from the server side:

# as root
tail -n 5 /var/log/xrdp-sesman.log
loginctl list-sessions
ps -o user,pid,cmd -C xfce4-session

Debian's log showed Session in progress on display :10, Ubuntu's Session started successfully for user ana on display 10; loginctl lists ana without a seat, as remote sessions appear, and ps shows ana's xfce4-session.

Clipboard, shared folders and sound

The clipboard needed no setting: text copied on the server pasted on our client and back. In Remote Desktop Connection it is the Clipboard box under Local Resources. A shared folder is called drive redirection in RDP, and in xfreerdp3 it takes one option:

# on your Linux PC, as your normal user
mkdir -p ~/shared
xfreerdp3 /v:localhost:13389 /u:ana /cert:tofu /drive:shared,/home/YOUR_USER/shared

On both servers it appeared as ~/thinclient_drives/shared, and files copied both ways. Remmina has a Share folder field in its RDP profile for the same thing; we didn't test it in this lab.

Sound needs an xrdp module for the server's sound system. Both installs chose PulseAudio. Debian 13 has no xrdp module for PulseAudio, and Ubuntu's session offered only a dummy output, auto_null. Both archives do have pipewire-module-xrdp 0.2-2, so switch to PipeWire:

# as root (on Ubuntu 24.04, pipewire-module-xrdp is already installed)
apt-get install -y pipewire-audio pipewire-module-xrdp pulseaudio-utils
loginctl terminate-user ana

# as ana, in a terminal inside the remote desktop
pactl info | grep "Default Sink"

pipewire-audio replaces PulseAudio. After a fresh login both systems printed Default Sink: xrdp-sink, and on Debian a test tone set it to RUNNING while xrdp's log showed the client agreeing sound formats. Our client had no speakers (FreeRDP's silent test backend), so we didn't hear it, and we didn't test the microphone.

Troubleshooting: what we broke and how we fixed it

How much RAM a Linux remote desktop uses, and which plan

These are the "used" figures from free -m in our 3 GB lab VMs, measured after clearing the file cache:

Ubuntu's session ran 59 processes, including the ibus input-method service and Evolution's calendar services, so each user costs about twice as much. With no graphics card, drawing uses the vCPUs. Our sizing for RS Computers plans:

VPS Nano (1 GB) holds an idle desktop but not a browser. VPS plans share their vCPUs; VDS plans have dedicated ones. RS Computers runs these KVM servers in Amsterdam, Dublin and Prishtina with NVMe disks, unmetered traffic and their own IPv4 and IPv6; availability by city is on the plans page, and you can move up a plan later from the client area with a short reboot. For a practice desktop, see our Linux and DevOps lab guide.

When a Windows VPS is the better choice

xrdp fits when your tools run on Linux: a browser, a code editor, scraping or automation you want to watch. There are no per-user licences, and RAM is the real limit (xrdp's default cap is 50 sessions). Choose Windows for Windows-only software such as MetaTrader, desktop Office or accounting programs, or for people who expect Windows. We offer it on VPS Mini and the VDS plans: see Windows VPS and our guide to connecting to a Windows VPS. More than two people at once on Windows Server need RDS licences, as our RDS grace period article explains.

Frequently asked questions

Is xrdp safe to use on a VPS?

Yes, if port 3389 isn't open to the whole internet. Debian 13's xrdp 0.10.1 carries the August 2026 security fixes, while Ubuntu 24.04's 0.9.24 relies on Ubuntu Pro for at least one critical fix. Reach xrdp through an SSH tunnel or a VPN, allow TLS only, disable root logins and keep the server updated.

Why does xrdp show a black screen after login?

In our tests it came from the same user already having a desktop: a console login through LightDM, or a session left behind by restarting xrdp. The sesman log then says the window manager exited quickly. End the old session with loginctl terminate-user and disable LightDM.

Does xrdp work with Windows Remote Desktop Connection?

Yes, and Microsoft's own xrdp guide uses it. Remote Desktop Connection (mstsc) connects to xrdp on port 3389, or on localhost:13389 through an SSH tunnel, shows a certificate warning because xrdp's certificate is self-signed, and then xrdp's own login window. xrdp doesn't support NLA (Network Level Authentication), so turn NLA off in a client that insists on it.

How much RAM does a Linux remote desktop need?

In our lab, Debian 13 with XFCE used 324 MB idle and about 160 to 195 MB more per logged-in user, and Firefox with one page added about 600 MB. A 2 GB VPS fits one person with a browser; plan roughly 1 GB for each extra person who browses.

How do I share a folder over xrdp, for example with Remmina?

Use drive redirection: /drive:shared,/home/you/shared in xfreerdp3, or Share folder in a Remmina RDP profile. The folder appears on the server under ~/thinclient_drives/shared, and in our test files copied both ways.

Debian 13 or Ubuntu 24.04 for xrdp?

Debian 13 was smoother in our lab: a newer xrdp with the 2026 security fixes, XFCE as the default session, an xrdp process that can read its TLS key without extra steps, and about half the RAM per user. Ubuntu 24.04 works too once xrdp joins the ssl-cert group and each user has a ~/.xsession file.

Your Linux desktop, one tunnel away

Done this way, xrdp gives you a desktop you can close at night and find exactly as you left it, with port 3389 never facing the internet. Pick a server on the VPS and VDS plans page, or message us on Telegram if you would rather have us set it up; setup work is quoted per job.

← All articles