Skip to main content

Connecting with remote desktop (rdp) to a linux workstation

If you would like to connect to your Linux workstation the same way you connect to Windows workstations, or if you want to be able to connect from any Windows system to your Linux desktop without any other programs, than you probably want to use Remote Desktop Protocol. The good news is that Linux has an open-source implementation of the RDP protocol!
Basically, the solution uses the following:
  • xrdp to have your own RDP-speaking server - which will allow you to connect using Microsoft Remote Desktop, or any other client implementation (rdesktop, remmina)
  • X11vnc will provide the interface to your desktop (it connects to an active X session, unlike other VNC servers which create a new session)
First, you need to setup X11vnc and make sure it works properly; then you can setup xrdp and make the connection between xrdp and x11vnc. Then you are done.

  1. Setup x11vnc
    • install x11vnc on your system (e.g. apt-get install x11vnc)
    • configure x11vnc to start when you login (via the GUI). Basically, run the following command as part of the user startup scripts (e.g: Xfce Settings Manager -> Session and Startup -> Application autostart):
      • x11vnc -usepw -display :0 -forever -clientdpms -repeat -xkb -gone 'xlock&'
    • Here's what the options do:
      • usepw - first time asks for a password (so make sure you run the command from the command line), then it allows access only if the password is correct. In theory, x11vnc can use system login, but it hasn't worked for me. Look into the man page for other types of authentication
      • display :0 - which XServer to attach to. Leave :0 if unsure
      • forever - after the first client disconnects, the server restarts and accepts other requests
      • clientdpms - try to blank the attached screen(s) on the remote computer - so that others can't see what you are doing (like RDP, and unlike traditional VNC). Please note, there are ways to override this and you are not 100% protected! See x11vnc manual for details
      •  repeat - allow keyboard repeat (otherwise keeping up-arrow pressed generates just one event). Disable this option if you notice you get a lot of keys repeated when pressed only once.
      • xkb - allows you to use your full keyboard layout (without it, sometimes SHIFT doesn't work, so it's better to keep it enabled)
      •  gone - what program to run when the user disconnects - normally this should lock your terminal, or start a screensaver, so that others will not have direct access to your workstation. Replace xlock by your favourite locking program (e.g. xflock4 for xfce)
    • Once you have setup and started x11vnc, do some tests (connect with a VNC viewer on port 5900), and see if everything works as expected. Please note, the configuration above was tested on a dual-display setup (with Xinerama) and both displays are exported and available through VNC.
  2. Setup xrdp
    • install xrdp on your system (e.g. apt-get install xrdp)
    • change the xrdp configuration so that it can connect to x11vnc:
      •  add this to your /etc/xrdp/xrdp.ini as section xrdp1 (so that it will be the default:
      •  [xrdp1]
      • Rename or remove the other xrdp* sections from the config file, so there are no overlapping section names.
      • Save the config file and restart xrdp/sessman: /etc/init.d/xrdp restart
      • Now, you should be able to connect to port 3389 (RDP) and you will get a xrdp login window. The login credentials supplied here will be sent to x11vnc for validation. Please note, that in this setup, x11vnc only asks for a password, but xrdp asks for username and password - in this case, the username can be anything.
      • Once the login is successful, you will get a debug window and control is passed to x11vnc. 
      • Once you are done testing, you can add iptables rules to disable access for port 5900 from the network, because it will be accessed only from the loopback interface. Or you can leave it on, in case you want to connect just by using VNC...
xrdp login window
xrdp connection to x11vnc
connected - the remote side is the window with the green desktop

This method has the advantage of bringing a "terminal services" experience to the Linux desktop - you can start an X session, start some programs, leave the session running on your workstation, and connect remotely from anywhere and connect to the actual session, being able to manipulate the same programs you have started. 

Disadvantages and caveats:
  • vnc is usually slow
  • the communication between xrdp and x11vnc is not encrypted (credentials and data is passed in clear-text), but this communication takes place just inside your workstation (local)
  • the communication between your RDP client and xrdp is done either unencrypted or lightly encrypted - so, it would be advisable to use ssh tunnels, or VPNs for the actual encryption.
  • the xrdp server can't resize your desktop to fit the client window (like the windows version can), so it's better to use clients which have scrollbars, or to specify in the x11vnc configuration the scaling of your desktop. As a Linux RDP client I recommend using remmina because it can pan and scroll if your remote desktop is larger than the local one.
  • You can have only one connection/only one user - or you will need to adjust your config (mainly the vnc ports) if you need more than one connection.
Give it a try and happy remoting :)


Unknown said…
Hello I have tried various options (clientdpms, forcedpms also blockdpy mentioned on offical site for x11vnc. My problem is that when I am connected via VNC client to x11vnc the monitor is displaying same activity as is shown on VNC client. Is possible to have local monitor locked and show activity only on VNC client? Thank you.

Popular posts from this blog

Home Assistant + Android TV = fun

Here's a quick setup guide for controlling your Android TV from within Home Assistant. I've used it to control a genuine Android TV (Philips 7304) and an Odroid N2 running Android TV. For this to work you need ADB access. It can usually be enabled from within Developer Settings. The great part is - you don't need root access! The most important things are described in the androidtv component for Home Assistant: Make sure you go through the adb setup. My configuration is simple (inside configuration.yaml): media_player:   - platform: androidtv     name: TV Bedroom ATV     host:     device_class: androidtv Once Home Assistant restarts, your TV might require you to accept the connection (adb authentication). This happens only once (or until you reset your ATV to factory settings). Once running the integration will show you the current ATV state (on or off) and allows you to turn it on or off.

SmokePing + InfluxDB export + docker + slaves + Grafana = fun

I've been working for a while on this project - with the purpose of getting SmokePing measurements from different hosts (slaves) into InfluxDB so that we can better graph them with Grafana. The slaves run multiple Smokeping instances inside Docker so that they have separate networking (measure through different uplinks, independently). This will not be a comprehensive configuration guide, but a quick "how to" to handle setup and basic troubleshooting. It assumes you already know how to set up and operate a regular Smokeping install with or without slaves and that you are fluent in Smokeping configuration syntax, know your way around Docker and aren't a stranger from InfluxDB and Grafana (sorry, there's a lot of information to take in). 1. Getting Smokeping with InfluxDB support - you can get it either from the official page (most changes have been merged) - (PR discussion here:

Downloading https web content - the hard way (for wireshark fans)

Problem: You want to download some content (e.g. video) from a website that doesn't want you to download that content, only to stream it. You may want to do this to view it later (maybe it expires after a while), or to view it offline or on a different device. Please note that circumventing the content owner's wishes against downloading may be a legal problem, but there are less sofisticated ways of doing it (e.g. screen recording either software or with a camera pointed at your screen), so we'll analyze it from a technical point of view. Up until recently, downloading video content was fairly easy, by starting the debugger (F12 in the browser), going to the network tab, identifying the video resource, copying the curl command and pasting it somewhere for offline download. But the sites got clever and detect when you open the debugger and stop accessing the video content, so that you can't find the video link. The solution to this is more convoluted - we're going t