Xrdp: An open source RDP server | Hacker News Reader

Xrdp: An open source RDP server

github.com

194 pointstomato2juice78 comments

So a long time ago I worked volunteer IT for a fan convention. This is roughly mid to late 2000s. Among many other things, I was constantly looking for ways to speed up the registration line. And rather than have reg workers type things in, one way I hit on was to have terminals there for people to enter their own information.

Shoestring doesn't even begin to cover it. Buying computers was definitely out. So I hit on the idea of buying used Wyse Winterms. Winterms are thin clients that talk either RDP or Citrix ICA. These could be had for about $20 a pop on eBay. I would hit local pawn shops, thrift stores and recycling places to get monitors and keyboards to go with them.

But they're just dumb terminals with Windows CE on them. How to actually use them?

xrdp!

I set up a Linux system with xrdp and a bunch of X sessions for the Winterms to talk to. Took a lot of fiddling to get it right. Like I probably spent two weeks in the evenings getting everything right. But even I was surprised how well it worked. With a full-screen web browser in kiosk mode it shaved massive amounts of time off how long it took to get through the reg line.

We actually used that setup for about three years before we had enough money to invest in better hardware. Over that time I'd estimate about 8,000 people used them. But I'll always have a soft spot for those stupid Winterms and xrdp.

I used those same winterms too. The problem was we were then updating our network for PCI compliance and one of the issues we had was our call centre teams used old green screens which were connected to via telnet and there was no way to update these winterms to install PuTTY.

Then I hit upon the idea of using them as even more dumb terminals. So I set up a PXE server that would serve an NFS volume hosting a minimal Linux distro and setting those winterms to boot via DHCP.

Surprisingly those winterms not only supported Linux but ran it really well.

This system ran for several years until those old green screens were replaced with web front ends instead. Which made me sad for two reasons, firstly the end of the PXE solution which works so smoothly, and secondly seeing the old green screen server decommissioned, which was a Sun SPARC box bought in the 90s and had an uptime of something ridiculous like 8 years.

Around the same time a number of us working furry conventions on the west coast had about the same idea, but we noted that many of the terminals of the time had a browser session type, so we ended up using that and web based kiosks for terminals.

These days the same software (now used at a number of conventions) is used with mobile devices and the need for having convention-provided kiosks has slowed quite a bit.

People still forget their passwords all the time.

Another option is http://xpra.org/ . It’s a bit more of a commitment as (from what I understand) it replaces you displayManager (e.g. Gnome gdm) and I haven’t gotten around to trying it but I personally prefer Xforwarding over rdp.

Is the difference between RDP and xforwarding basically RDP is giving you a video of the remote display and sending the mouse clicks + XY position top? Vs xfowarding which natively renders the buttons and such and in the button example sending signal that a particular button got clicked?

I imagine a trade off is more security vulnerabilities with xforwarding? Does some have more incite into this?

For me, XPRA has been a revelation for how I use Linux remotely. It's the GUI version of the "screen" command.

For those who haven't used it and want to try it, you install "xpra" on your Linux box with "yum" or "apt", then fire up an xpra server with "xpra start" (or "nohup xpra start &"), then make a note of which extra display it has added (like ":1"). It's not replacing the display manager (as far as I'm aware).

Download a windows client from xpra.org, then connect through SSH. Once connected, you get a small icon in the Windows taskbar with lots of menu options. Under the "Start" option, you have sub-menus which give you access to all the Linux desktop programs on the target machine.

For example, I use XPRA to connect to my Ubuntu 20.04 laptop and run "Start -> Accessories -> Terminal Emulator". It opens an XFCE4 terminal on my Windows desktop, looking as if it was a native Windows application. In the terminal, I can type "thunar" and a new Thunar file manager window will open on the Windows desktop, or "xemacs" for a text editor.

It's very fast because it's only sending 1 window at a time, not the whole desktop. I can disconnect, then re-connect and the windows will re-appear as I had left them.

It's not perfect (some dialog boxes don't respond to mouse clicks), but it is worth playing with.

I haven't tried xpra specifically, but from your description it reminds me of regular X server running on either windows or mac is (xming and xquartz respectively).

Nope, completely different. Xpra is resistant to network failures, while X server requires a stable network connection to keep the apps running. Xpra is also completely agnostic to the applications GUI: it just streams video and input events.

Rough X vs Xpra sketch:

                          |                    |
  display <-> X server    | <----X proto-----> | app
                          |                    |
                          |                    |
  display <-> Xpra client | <---h264/input---> | Xpra server <-X proto-> app
                          |                    |
                          |~~~~~~network~~~~~~~|

thanks for the explanation!

> Is the difference between RDP and xforwarding basically RDP is giving you a video of the remote display and sending the mouse clicks + XY position top?

That's not at all how RDP works, that's how VNC works. RDP basically considers your display (and sound, clipboard and devices) as though they were connected to the server. Have a 4k display locally but only some crappy 1024x768 relic connected to the server? Doesn't matter, you can have a 4k desktop. Cut from your local stuff and paste to your remote stuff. Print from a remote program to your local printer. Configuration is just a few checkboxes.

I use RDP multiple times every day. I have tested Linux RDP server implementations and they are very buggy and really not production ready only NX kinda is (yet not as good as MS RDP). VNC is so bad and lacks so many features that it's not even considered a competition - it's old insecure slow protocol that should be forgotten by now.

RDP isn't really meant to be cross platform, right? It's a Windows graphics server telling a Windows client how to draw some Windows widgets. The fact that there are working Linux implementations at all is impressive. By contrast, VNC is pretty close to just sending an image of the screen, with some clever optimization.

VNC over SSH should be as secure as you need, but it's never likely to be as performant as RDP.

> It's a Windows graphics server telling a Windows client how to draw some Windows widgets

In the 90's when everything was made of lines and rectangles, you're right that this deep integration made RDP perform much much better.

Now though, nearly all applications are composited bitmaps (webviews, opengl surfaces, etc). There isn't much scope for sending the raw draw calls over the wire anymore, and instead using some video codec to send the surfaces as bitmaps, and then compositing on the client is about the best you can do.

VNC doesn't even do that though...

There is an official RDP client for macOS. I use it every to connect to the Windows PC under my desk, while using the monitors on my laptop.

keyword: client, not server.

This is part of why Windows is my main boot OS on my desktop. Remoting into Linux (whether it's my SBCs, laptop, or a VM) from Windows is easier and works better than the opposite.

Although VNC allows multiple users to view the same screen at the same time (and fight over the mouse if they wish).

In all seriousness though it's useful if you use VNC just to remote monitor a screen and want to leave it open indefinitely.

Also RDP uses TCP and UDP which makes it bad for SSH tunnelling, as opposed to VNC which is TCP only and easy to tunnel.

RDP can be limited to TCP. Microsoft's client autodetects whether UDP is available and can work without it.

I'm not an expert on RDP. But I tunnel RDP over SSH all the time... What am I doing right?

it's very common to use RDP over an SSH tunnel. it's not great in low bandwidth situations, of course. but in today's world, it's usually fine.

It works much better in low bandwidth situations if UDP is also available because then things like "the user just closed this application, stop downloading this picture" can happen.

With TCP multi-megabyte buffers can end up forming and when you've shoved data into TCP there's no way to cancel sending it.

We have xrdp running for several years now. It works fine but took some effort to get there:

- Compile it yourself. The package that comes with your distribution is bad and has things like copy/paste disabled.

- Configuration of authentication takes some effort.

Any chance yo can point me at any notes you have about compiling it? I haven’t managed to do it with latest source successfully.

Try this: http://c-nergy.be/blog/?cat=79

VNC supports TLS... What part of that is insecure? By my experience I can't see in which use cases it would be slow either, but they possibly exist...

For me VNC feels more sluggish than RDP. I can tolerate working with RDP to a server over Wi-Fi over a DSL line. VNC between two computers on my home network (client on Wifi and server on wire) feels laggy. If I connect the client to a wire, it's tolerable.

I used to maintain some linux remote desktops at my job for specific workflows of certain employees.

Wow, using xrdp was a complete gong show to manage. The most common bugs were in the assignment of displays on user logon, as well as a crappy, often buggy, login screen (though GUI logins for linux are fascinatingly weird pretty much universally.)

That being said, even in evaluating alternatives there wasn't anything much better. Linux remote desktop managers are just not that great yet.

As much as I hate Windows, I have to tip my hat to Microsoft's and say that their RDP implementation stands more than head and shoulders above any alternative remote desktop implementations I've tried.

Developers these days are getting much better at doing things over the command line. The trend of using GUIs for everything recently appears to be ebbing into a "right tool for the right job" mindset. Which is a very promising trend I've noticed. Hopefully remote workflows are entirely done through emulating terminals over SSH in a few years time :)

If your primary use case is Linux, xpra is very good.

Unlike RDP, xpra defaults to passing over individual windows — it acts as windows manager for it's own Xorg process on server. This can completely side-step the hassle of wrapping and interacting with existing desktop environment, it's login screens etc. Xpra uses unmodified Xorg server from your distribution with xf86-video-dummy driver to achieve this. Mirroring existing Xorg session is also supported (but slower).

How windows rdp manages multiple monitors, and window resizing when you aren’t on a full screen is bananas compared to vnc, the only problem I had is sometimes it d

The resizing/scaling behavior varies widely depending on which of Microsoft’s three RDP clients you were using

(Not kidding)

> That being said, even in evaluating alternatives there wasn't anything much better.

Do you remember what issues were there with NX? I found out pretty much to "just work" and with a really good performance too.

I used NX years ago. Setting it up required fiddling, and it periodically broke. TigerVNC is my current favorite for Linux servers. Cloud gaming is a different world of protocols.

Xrdp has been buggy for me as an RDP server... but... it's been a godsend as a VNC proxy.

The student computers at my lab run Windows and do not allow user's to install software or run foreign executables. They have great monitors though. I use an RDP instance to access my VNC linux boxes remotely.

Windows 7 and Windows 10 come with a built-in RDP client.

Also, VNC is pretty insecure. So I only listen on localhost, then connect via RDP for authentication.

Can someone explain to me how Xrdp is so much simpler to use than VNC? I setup a new CentOS workstation the other day and ended up trying to follow long tutorials with config files and services. I gave up, installed the Xrdp package and seconds later I had a remote session going.

I haven't fully traced how it works, but Xrdp is built on top of a vnc backend (you can see the vnc folder in the github directory structure), but it manages all of the configuration and negotiations automatically.

If you do a `ps -ef | grep vnc` while you're connected via Xrdp you should find the underlying vnc sessions. Something like:

Xvnc :32 -auth .Xauthority -geometry 1920x1080 -depth 24 -rfbauth....

It's been a bit mixed for us. As a sysadmin for non-technical users who need some linux access, it's wonderful because it's so much easier for them to connect. The stability has left quite a bit to be desired though - I have to nuke quite a few sessions and have them start from scratch.

>long tutorials with config files and services

On the server:

    x11vnc -display :0 -noxdamage -shared -repeat -forever

On the client:

    ssh -T server 'nc 127.0.0.1 5900'
    vncviewer 127.0.0.1:5900

    ssh -N -L5900:127.0.0.1:5900 user@server

is usually cleaner than using nc, it doesn't require running any commands on the remote system and lets you do any port changing that you need to make things work between each side.

Right, I had to use `nc` instead of forwarding the port from SSH itself because I use systemd socket activation for that ssh command, with

    ExecStart=ssh -T server 'nc 127.0.0.1 5900'
    StandardInput=socket
    StandardOutput=socket

in the service file and

    ListenStream=0.0.0.0:5900

in the socket file.

The socket has to be connected to stdin/stdout instead of using SSH forwarding since SSH doesn't support fd-based socket activation.

Yea that's definitely a bit more of an edge case. and for the downvoted sibling commentor, this is the same kind of setup that previously would be done with inetd or xinetd and the lack of security or monitoring or logging that that usually entails. I'd be surprised if there's not some other way to do it but this seems like a perfectly fine work around otherwise.

Why must systemd break everything?

It is like a vandal with a baseball bat.

x11vnc for the win. A really useful and somewhat underappreciated tool.

I've never had a problem setting up tightvnc or tigervnc. I've even run it to get an X session going on Android devices.

Xrdp has an advantage in that it allows Windows to talk to Linux servers with its own Terminal Services client stack.

I guess YMMV; I couldn't make it work. VNC on the other hand is terribly slow.

The only solution that worked for me, both configuration and performance wise, is sadly closed source - NX Server (which is excellent).

Xrdp also used to be difficult to setup on Linux, but (ironically) systemd + modern session management has made RDP on linux behave pretty well.

Also, if you look carefully at the default config mechanism, Xrdp does RDP to VNC translation internally, and runs Xvnc for each login.

> ...ironically...

Why is it ironic? I've been using systemd since before it was part of any distribution; it has been extremely convenient and helpful from the very start, and every year it gets even better (as new components mature enough to enable, e.g. systemd-timesyncd).

Ironically because the opinionated consistency Systemd's session + login management brought made Xrdp saner to operate, while changing traditional things like persistent process after log off (by default), and device-console/session attachment.

Same here - CentOS 8 + VNC, tried to setup myself for a couple of hours, then asked admin to help, ended up with Xrdp in 5 minutes.

what setup is there to do for VNC ? just run x11vnc and connect to your ip:5900... or directly X11 forwarding

Tried to use xrdp on couple clients' machines and gave up at the end after 2 months (Ubuntu was used as host and client). Always had problems starting with keyboard layouts, xdisplays, remmina client, and ending with black screens (https://github.com/neutrinolabs/xrdp/issues/1358). Also, it requires a very good connection, if you have sometimes a long ping - your clients would be randomly frozen. The solution only restart sessions on host. Very unstable not only xrdp itself, but xorg, vnc, xdisplays, etc within protocol implementation, at least for Ubuntu.

Even having working it was much slower than on windows stack within same datacenter.

I've recently heard good words about x2go. I didn't know about it earlier. Maybe it could save someone brain cells :)

For myself I decided do not use the RDP protocol on linux clients' machines.

Maybe Spice is the answer. It works good on VMs.

I wish Spice worked better. Right now I'm running my workstation on a server KVM instance. Spice too laggy for me. VNC works great.

Although, I leave a connected tty backgrounded with Spice -- the audio works seamlessly. Small bits of lag, but I use it for spotify in the background.

In my experience, SPICE is awesome on a fast local network. I even run it at 4k with a remote VM. I experience more frame drops than straight up lag - but things like video and audio are surprisingly good.

I've been searching for a good (free) virtual desktop/workstation solution but Proxmox as a host + SPICE so far as the best I have found. I'd love to also find something free that supports virtualized or pass-through GPU. I agree that SPICE is not perfect, but it's the only protocol that feels like I am actually using the remote machine as a local desktop unlike VNC or RDP.

Is there any way to run spice on real hardware? I can only find drivers for VMs

xspice

In the past I've used and loved https://xpra.org/ .

The performance is good and it doesn't rely on weird (to me) installation like NX does (NX installation creates a unix user, maybe this is necessary for some enterprise-y things, but my use case is "a smoother VNC").

I seem to recall facing issues with having exactly the same version on both client and server because the code didn't try for any forward or backwards compatibility, don't know if that's still the case.

Just posted something on xpra too! https://news.ycombinator.com/item?id=23494012

A few years ago, I managed to build XRDP with RemoteFX enabled. This was the smoothest remote desktop I have ever experienced.

I couldn't replicate it a while later after an OS upgrade and I have since given up on it. Does anybody else have experience with this? Should I give it another try?

Have a look at https://github.com/rcarmo/ubuntu-xrdp. I _think_ it has RemoteFX enabled, but to be honest I haven’t delved into the internals for a while and last time I did I was trying to get audio working.

And then there is Teradici’s PCoIP hardware, which is shockingly good. It compresses and encapsulates video, audio, and device data. You just install a card into your machine at one end and run a thin client box at the other end - or use a software client.

The quality is amazing.

Nvidia and Amd video cards (and probably also intel) have done the same thing for a while.

I would usually have gone for vnc and have used TigerVNC on my Mac - you can even run a VNC server and desktop in a Docker container. I actually learned about xrdp over the weekend whilst trying to help an inlets user connect to his remote lab in Edinburgh from Vienna. There's a couple of screenshots here showing it in action - https://twitter.com/alexellisuk/status/1269639837335904257?s... - inlets PRO is a pure TCP tunnel with TLS encryption https://inlets.dev/

If anyone wants to have a go at a “normal” end-to-end user experience, I have a Docker setup with Xrdp and audio enabled at https://github.com/rcarmo/ubuntu-xrdp that I poke at now and then, and loads of previous attempts at the same all over my GitHub (many of my “desktop app” containers have VNC, Xrdp or Guacamole bundled in for remote access from my Mac and iPad).

Right now the biggest issue I have with RDP on Linux is that the default packages that ship with most distros are useless—they are either outdated (still in VNC proxy mode) or poorly integrated with login managers. Also, even though I get “free” multi-head when accessing a Windows desktop from my Mac (and believe me, that is an amazing way to work on a daily basis) I have yet to get it to work 100% with a Linux server (it works and I get multi-head, but sometimes displays are swapped for some reason).

Many people don’t “get” RDP because they confuse it with VNC and other remote display solutions. But when it is set up properly, it is _massively_ better than VNC, NX or Xpra in terms of bandwidth, latency, and client support (yes, there are thousands of VNC clients, and every Linux box can do X over SSH, but I can use RDP from my iPad, Android, etc., and those are the thin clients I travel with).

I've been using xrdp for headless Raspberry Pi installations running Rasbian for years. It's easy to install and is a way smoother experience than vnc. Connections from Windows and Linux have rarely ever been a problem. Connecting from Android used to be an issue, but I think even that has been resolved at this point.

We run over 500 concurrent desktops with Guacamole and XRDP in Kubernetes in non privileged conatiners. This allows us have a secure environment while still having it light weight and not having te resort to Citrix for example.

Anyone comparing VNC to RDP favorably is nuts. RDP is a much more optimized protocol for high latency, low bandwidth. Only Citrix compares favorably from user's point of view. Maybe NoMachine NX as well. Both i cannot get to work over https (nomachine) and kubernetes (citrix).

Not requiring a custom, vague client also helps.

XRDP uses a Xorg driver or is able to use a VNC backend. Even then its faster than VNC. It can use pam for authentication.

Xrdp is now used by Hyper-V Enhances Session Mode. It performs great.

Personally I encountered a problem that Xrdp recognizes wrong keyboard layout (I use JPN Windows and US keyboard, but recognized as JP keyboard in Xrdp)

so, is there any open-source alternative including a login manager and preferably supporting accelerated graphics - xrdp is no solution you can sell anyone today just from the looks of it? I suppose the state of this affair is, what is really killing Desktop-linux deployment - to my knowledge you can't setup a VDI-infrastructure a la Windows Terminal Server at all without buying into Citrix or various other vendors (at which any "clients can be cheaper with Linux" argument is just obliterated)

x2go always worked well for me.

X2Go was great for me also. Installation is quick (compared to xrdp), and screen loads faster.

I've been using xrdp more extensively with WSL2 recently. Because WSL2 often gets a new network interface assigned, X connections back to Windows are terminated, while rdesktop to xrdp running on the WSL2 instance does not.

RemoteFX is active, but on my 2560x1440 display there is still a bit of sluggishness. However, it's fine to run PyCharm locally on the WSL2, which is my primary use case with this.

I used this as a solution for remote workers in my company. Set up rdp on Windows with 24-bit color and select "LAN" connectivity improves sluggishnes. It takes a bit of tinkering to get the xRDP config working well, but when it works, it's really smooth. I used X over RDP. Make sure no users are locally logged in before logging in via RDP.

I've been recently evaluating vnc and xrdp for a project. xrdp was much harder to install and configure. Documentation was sparse and outdated. VNC provided multiple choices of well established implementations and in low latency environment with simple Desktop (xfce), both provided pretty good feel.

Headless?

In the Features section of the xrdp GitHub project page is this: "Connect to a Linux desktop using RDP from anywhere (requires xorgxrdp Xorg module)"

Does this imply that serving from a headless Linux machine is not possible like we can with vncserver instances?

No. It means that you need an X server willing to provide access to the bitmaps inside it using that module, but you can run Xrdp fully headless against a memory buffer (like VNC does with Xvnc) or proxy via RDP to an in-memory VNC server (which is the “old” way of using Xrdp).

Not sure why you would use this over `ssh -Y`, so I guess it's for Windows users to experience the joy of the "Linux Desktop"?

MacOS sorely needs an RDP server though. VNC is an awful UX for me and idk why. Didn't start off that way.

X11 is an extremely chatty protoy. Try it over a higher latency connection (say, across the US from you) and you will notice that it can take minutes before even xterm will show up.

Also, another benefit of VNC is that it's like tmux: if your session gets interrupted then your programs won't all get HUP'd.

Wow. i'm glad i found this. I've been looking for a way to connect to my laptop running Ubuntu 20.04 from my desktop running windows 10. I tried a few other programs before but they weren't compatible with windows rdp.

Does it support UDP?

xrdp is nice but i prefer rdesktop since it's more established

Rdesktop is a client, xrdp is a server.

Reply on news.ycombinator.com