xrdp: running a Linux desktop over Microsoft's RDP protocol

The problem xrdp solves: speaking RDP to a Linux box

Windows ships an RDP client. macOS, iOS and Android have Microsoft Remote Desktop. Linux desktops do not have a Microsoft RDP server, and that is the gap this project fills. The README states that xrdp "provides a graphical login to remote machines using Microsoft Remote Desktop Protocol (RDP)" and lists FreeRDP, rdesktop, KRDC, NeutrinoRDP, mstsc.exe and Microsoft Remote Desktop as clients it accepts. The intended audience is an administrator or a user who wants to reach a Linux machine from one of those clients rather than installing a VNC viewer on every device. The README also notes that RDP transport is encrypted using TLS by default. That is a meaningful default, because it means a fresh install is not sending keystrokes in the clear, though the certificate handling behind that default is something you should check yourself rather than assume.

xrdp is a front end, not the session: libxrdp, sesman and xorgxrdp

The repository layout makes the architecture legible. libxrdp holds the core RDP protocol implementation. The xrdp directory holds the main server code that accepts connections on 3389/tcp. sesman is the session manager, with libsesman for code shared between sesman and its tools, and chansrv as the channel server that carries clipboard, audio and drive redirection. The README is explicit that connecting to a Linux desktop requires xorgxrdp, a separate Xorg module hosted in its own repository. When xorgxrdp is not available, the README says to use an Xvnc server instead. That is the central design fact about xrdp: it terminates RDP and hands the session off, and the quality of the resulting desktop depends on the backend you give it. The xup directory is the xorgxrdp client module, which is how the two halves meet. There is also a vnc module and a neutrinordp module, which are what make the RDP/VNC proxy mode possible: xrdp can sit in front of another RDP or VNC server rather than a local X session.

Installing xrdp on Ubuntu, Debian, Fedora and RHEL

The README's Quick Start says most Linux distributions carry the latest release, and that you want both xrdp and xorgxrdp for the best experience, with xrdp recommended to depend on xorgxrdp. On Ubuntu and Debian the install is a single package:

apt install xrdp

On Fedora, RHEL and derivatives, the README says to enable EPEL first if you are not on Fedora, then install xrdp:

dnf install epel-release

dnf install xrdp

After that, xrdp listens on 3389/tcp. The README states plainly that your firewall must accept connections to 3389/tcp from wherever you intend to connect. If you would rather build from source, the README gives a four-command sequence after unpacking a tarball or cloning with submodules:

./bootstrap
./configure
make
sudo make install

Building from a checked out repository needs autoconf, automake, libtool and pkg-config on top of gcc or clang, make, openssl-devel, pam-devel, libX11-devel, libXfixes-devel and libXrandr-devel. The clone command in the README is git clone --recursive, and skipping the recursive flag leaves you without the submodules.

Where xrdp stops short: audio, architecture and the missing backend

Two limitations are stated in the README rather than discovered later. Audio redirection and microphone redirection both "require to build additional modules", with a wiki page for the PulseAudio setup. They are not part of the package install. If your users expect sound from a remote session, plan for that extra build. The second limitation is architectural. xrdp primarily targets GNU/Linux, and the README says x86 including x86-64 and ARM are the most mature architectures. It also notes that components such as xorgxrdp and the RemoteFX codec have SIMD optimizations for x86, so running on x86 gets the fully accelerated experience. On ARM you are on a supported but less optimized path. The failure mode worth naming is the missing backend: install xrdp without xorgxrdp and without an Xvnc server, and there is nothing for the session manager to attach a desktop to. The README's own framing, that xorgxrdp is required for connecting to a Linux desktop, is the thing to read before you file a bug. This is also where xrdp is the wrong tool: if you want a browser-based console with no client software at all, or a protocol that is not RDP or VNC, xrdp is not the layer you are looking for.

xrdp against VNC: same goal, different protocol and different clients

The honest alternative for the same job is a VNC server, and xrdp is not purely a competitor to it. The README lists a VNC client module in the repository and describes an RDP/VNC proxy mode, so xrdp can front a VNC server. The difference in approach is the protocol and therefore the client. RDP is what mstsc.exe and Microsoft Remote Desktop speak, so an xrdp deployment asks nothing new of a Windows, macOS, iOS or Android user. VNC needs a VNC viewer on each device. RDP also carries channel features that the README lists as built in: two-way clipboard transfer for text, bitmap and file, and drive redirection to mount local client drives on the remote machine. Those are channel-level features, not add-ons. The trade-off runs the other way too. VNC servers are commonly the simpler thing to install on a machine where the desktop already exists, and xrdp's dependency on xorgxrdp means an extra package and an extra moving part. If your users are all on Linux workstations and already have a VNC viewer, the RDP advantage shrinks to the protocol features and the reconnect behaviour.

Session reconnect, resizing and the RDP/VNC proxy mode

The feature list includes reconnect to an existing session and session resizing, both on-connect and on-the-fly. Reconnect matters in practice because it is the difference between a dropped connection ending your work and resuming it. Resizing on the fly is the feature that most often decides whether a remote desktop feels usable on a laptop that moves between an internal panel and an external monitor. The proxy mode is the part of xrdp that gets the least attention and deserves more. Because the repository contains a vnc client module and a neutrinordp module, xrdp can accept an RDP connection and forward it to another RDP or VNC server. That turns xrdp into a single RDP entry point for a set of machines that do not all speak RDP, which is a different use case from remote access to the local desktop. The repository also carries tools alongside the server: the tools/devel directory has gtcp_proxy, a GTK app that forwards TCP connections to a remote host, and tcp_proxy, a CLI app that does the same. Those are development aids rather than production components, but they are part of what ships in the tree.

Licence, maintenance and what an upgrade costs you

xrdp is Apache-2.0, and the README carries an Apache 2.0 badge that matches the COPYING file at the top level. Apache-2.0 is a permissive licence with an explicit patent grant, which is generally the easier end of the spectrum for redistribution inside a company, but the obligations that apply to your specific distribution are a question for your own legal review rather than something to settle from a badge. On maintenance, the repository is not archived, and the last push was on 2026-09-16, which is recent enough that the project is being worked on. The release history shows v0.10.6 in April 2026, a release candidate v0.10.6.1-rc.1 in July 2026, and v0.10.6.1 shortly after. That pattern, a patch release preceded by a candidate, is worth knowing when you plan upgrades: there is a testing window between the candidate and the final tag. The upgrade cost itself is low if you stay on distribution packages, because the version you get is the one your distribution shipped. It is higher if you compile from source, since the build needs openssl-devel, pam-devel, libX11-devel, libXfixes-devel and libXrandr-devel and, from a git checkout, the autotools chain and recursive submodules. Mixing a source-built xrdp with a distribution xorgxrdp is the kind of mismatch that produces confusing session failures, so keep the two halves on the same origin.

Editorial conclusion

Adopt xrdp when the people connecting are on Windows, macOS, iOS or Android and you want them to use an RDP client they already have, and when you are willing to install xorgxrdp alongside it and open 3389/tcp deliberately. Do not adopt it if you need audio or microphone redirection without building the additional PulseAudio modules, or if the machine has no Xorg or Xvnc backend to attach a session to. Before rolling it out, verify that your distribution ships both the xrdp and xorgxrdp packages, confirm which backend sesman will use when xorgxrdp is absent, and read SECURITY.md in the repository for the current reporting guidance.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. neutrinolabs/xrdp on GitHub
3. Project website
4. README
5. Releases