Remote desktops

From Helpful
(Redirected from Remote X windows)
Jump to: navigation, search
Linux-related notes
Linux user notes

Shell, admin, and both:

Shell - command line and bash notes · shell login - profiles and scripts · Shells and execution ·· find and xargs and parallel · screen and tmux
Linux admin - disk and filesystem · Init systems and service management (upstart notes, systemd notes) · users and permissions · Debugging · security enhanced linux · health and statistics · kernel modules · YP notes · unsorted and muck

Logging and graphing - Logging · RRDtool and munin notes
Network admin - Firewalling and other packet stuff ·

Remote desktops
VNC notes
XDMCP notes

X windows over the network

(Side note: consider whether alternatives, such as TeamViewer, may fit your immediate needs better)

X is an inherently networked protocol.

Each X application is an X client that you can connect to any X server. Options:

  • Usually: the X server is on the same machine -- it's the thing displaying graphics on your monitor.
A number of modern extensions will only work when run locally -- notably hardware related ones, such as GPU features.
  • Remote: you log into a remote machine, you tell an app on the remote machine to contact your local X server over the network.
  • A third alternative made more sense in the early days of thin dumb terminals (cheaper computers that could do little more than display things): Connect such termanals via a permanent LAN to a server, make the server send a login manager to you.
The display manager is mostly just another app, except it presents a login prompt, starts your display manager on a desktop (which indirectly runs all your apps).

Note that any sort of remote X makes less sense over a large distance, or over wifi, as then the connection and the session are transient, meaning the app would die the first network hiccup.

If you want a remote X session that keeps running, look at ways of wrapping it - VNC, NX, Xpra, etc.

Some comparison

You can tell any X app (technically X client) to display on any X display it can reach.

In the typical case this is on the local machine (:0, :1, etc. - this is usually transparent because it picks up the the contents of DISPLAY environment variable)

In another common case this is an SSH tunnel (mostly just because end-to-end access over anything larger than a LAN is likely to be firewalled).

Setup Speed Details
ssh -X nearly none (assuming exising SSH server) Good (draw commands, small lag for encryption) Security (auth and encryption) is already handled. Some SSH servers disable X by default and you have to configire it.
X over local net fiddling with xhost Good (draw commands) Avoids SSH overhead. Host permissions may be annoying. Next to impossible over WAN, at least without VPN (and SSH may be simpler than VPN).
XDMCP + X server on local net More involved (various configs, networking details) Good (draw commands) Quite practical once set up properly. (and could be done via VPN-style network)
VNC Fairly simple (e.g. when following examples) Acceptable (bitmap difference) Session keeps running when you disconnect - can be handy
VNC + XDMCP Could be involved Acceptable (bitmap difference) Can be useful for multi-user setups. Less restricted than basic XDMCP since that part can be local to the server
NX Usually easy (sometimes a pain) Acceptable to decent Cleverer and faster than VNC. No additional auth (or encryption) details to think about as it just uses ssh. Some NX variations and combinations can be a little prickly to set up. If it works, it works, if it doesn't you may need to dig around.

Note that 'local net' is not necessarily restrictive - that is, VPNs can make it practical over a distance, as do ssh tunnels (as mentioned).

Note on speed: Nothing deals well with fast-updating graphics like fading images and video (even a gigabit LAN connection would only be acceptably fast). If you use a flashier window manager (like KDE and recent versions of gnome), you probably want to turn off things like fading, expanding/collapsing menus and such.

TODO: read and other things about NX

The longer version

Unless you know it well, you may want to skim over X terminology.


When you want to make X from another server come to you (or send it elsewhere) the easiest way is usually some form of tunneling, and the easiest among those is often tunneling provided by SSH.

SSH daemons on unices often supports tunneling X, and if the client you use also knows about X tunneling, most of the work will be done for you.

Usually, this works by having the SSH server allocate an extra display, such as localhost:10, and the X-tunnel-supporting client will point DISPLAY to this. To X clients running there, this looks and acts just like any other local (implicitly trusted) display, it just happens to be backed by a tunnel managed by sshd. This is also the reason you should not change the DISPLAY yourself. In the best case you send it to the same computer nonsecurely, but usually you'll just break it.

Of course, the ssh daemon has to support doing this, and it has to be enabled. It may be disabled for security/leanness reasons. If so, change your sshd config . Note that filenames tend to vary a little between versions and implementations - /etc/ssh2/sshd2_config versus /etc/ssh/sshd_config, that sort of thing.

For the fairly OpenSSH, the option is X11Forwarding yes. (Also, you want X11UseLocalhost to be its default, yes, unless you know that and why you don't.)

For the server, it's AllowX11Forwarding yes.

Clients usually allow it out of the box. If not, the option is ForwardX11 yes.

X servers

A graphical *nix workstation almost always runs an X server on your graphics card on display :0, and most support running others on :1, :2 and so on - some modern linux distributions use that ability to support user switching.

X itself is a networked protocol, so X clients and servers need not be on the same computer - or use the same OS. There are several interesting alternative X servers:

  • XMing is free and runs on Windows (no GL).
  • Cygwin/X is part of Cygwin, running under windows. Free, and runs the basics well.
  • WeirdX is an X server implemented in Java, also free.
  • Exceed is a commercial X server for Windows. In my limited experience it works well too.
  • Unix versions of VNC servers are X servers, which then serve the graphical result over their own, bitmap-based protocol. A number of VNC implementations are free.

And some I never used myself:

See also

X forwarding:


The X Display Manager Control Protocol (XDMCP) asks a remote host to connect to your X server.

It can be used to graphically login to a remote computer, and was mostly used for thin clients (you can use it now, but it's linited in that it doesn't persist sessions).

See XDMCP notes.


See VNC notes

VNC captures your screen and sends bitmap versions of it.

When you need cross-platformness, VNC (Virtual Network Computing) was historically the easiest choice, and occasionally still is.


  • No encryption run it over VPN if you care
  • Auth security looks decently secure(verify)
  • Various of the servers and clients are not in active development
  • ...and those aren't the fastest thing out there


  • The VirtualGL thing is actually quite well done
  • It being its own protocol makes it easily crossplatform
(e.g. unifying between X and others)


NX is a protocol by NoMachine.

Proprietary, free for personal use. (There is open-source though it's not actively developed)


Typically faster than VNC. Integrates VirtualGL, making 3D faster as well.

See also:


Roughly, NX 3 over SSH, with some


Mostly used in the context of virtual machines, e.g. being integrated into QEMU (use of SQL driver makes for lower latency), oVirt.

There's also Xspice, basically an analogue of Xvnc.

Secure auth and encryptions.

Initially closed-source, now open-source.

See also:


This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

ICA is primarily a channel multiplexer.

Screen content over ICA is actually thinwire, which e.g. has moving image detection [1].

This is used by Citrix - developed by them, in fact.

In practice, it's one of the nicest ways to run applications (instead of entire desktops) remotely, particularly in office environments.

Citrix (and Xen) notes


RDP (a.k.a. Remote Desktop, Terminal Services) started as a rebranding/spinoff/ripoff of ICA, simpler (and limited due to Citrix lawsuit threats).

rdesktop, tsclient, FreeRDP

Open implementations of RDP.

rdesktop is a CLI-started graphical RDP client.

FreeRDP is a fork that got some more development.

tsclient was (now discontinued) one possible GUI frontend for rdesktop.

You'ld now probably use Remmina, GNOME's or KDE's frontend - they and others tend to wrap/run varied clients.




This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Guacamole is a HTML5 (canvas-and-javascript) frontend to a guac server, where that (extendable) server typically relays to RDP or VNC backends.

In other words, it makes it easier to unify and expose those.

See also:

Xpra notes

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Xpra (tmux/screen-like) persistence for X11: Apps are actually displaying to a background process, and gets relayed to you when you connect to that.

If you're familiar with X: It's an X server and (rootless) window manager (The Xpra client can also sync clipboard, sound, and printers, forward notifications, and some other potentially nice things.)

Xpra was designed to be rootless, meaning you get individual app's windows, rather than a desktop containing them. (This because Xpra acts as a window manager itself)

(also means that in practice you may well want to start a shell, as in the examples below)

You can get a desktop mode, by starting a nested X11 server as the initial process. Which then uses another display and a little more thinking - see the docs)

Quick start:

# start a new session on display :100
xpra start :100 --start-child=xterm
# in practice it can make more sense to add your initial program(s) to ~/.xpra/xpra.conf

# connect to it locally to test:
xpra attach :100
# connect to it remotely (via SSH, it's handy to do the auth and encryption for you)
xpra attach

If you think the encryption is a bottleneck for you (or redundant because you're already on VPN), you can consider doing it via a direct TCP connection (optionally still with a password), something like:

# start like:
xpra start :100 --start-child=xterm --bind-tcp=
# connect like:
xpra attach

See also:

Winswitch notes



Intended for remote assistance, cooperation.

Unattended access also possible.

Speed seems good, e.g. a bit better than VNC tends to be.

Free version does what you want, paid version is slicker. And necessary for commercial use.


This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Connects, but no remote control

  • OSX
  • Linux
possible causes include
32-bit version doesn't work; try 64-bit version
configuration denying it
graphics driver?

GUI won't start


  • missing dependency
in my case, sudo apt install --reinstall libdouble-conversion1 helped (based on strace teamviewer)

Windows Remote Desktop

Remote logins

Remote logins, in the form of seeing another computer in a window and interacing with it, is possible when you have Windows XP or a recent server variant: both a server and the client, called either Terminal Services or Remote Desktop - it was renamed at one point.

On non-server versions of windows such as XP, there is a built-in limit that means you can only have one login at all, local or remote; logging in in one way will take over the same session, disconnecting the other. I forget whether this is fixable, but chances are microsoft doesn't really want you to do so. It's not a technological limit. In fact, they briefly promised it for SP2. I suspect it's rooted in the lessened motivation you would get to buy a server OS from them.

Interesting to note is that there is a linux client that works quite well.


To enable it or verify it is enabled, right-click on 'My Computer', click 'Properties', and find the 'Remote' tab. Check the checkmark named 'Allow users to connect remotely to this computer'.

Remote assistance is, I believe, the same thing but established through invitations (for helpdesks and the like) and likely allows the connected to computer to look too (regular remote desktop throws the computer itself back to the login screen once there is a remote login). I never used it, so I usually disable remote assistance. (And given windows' track record in security, I feel a little safer disabling things I never use anyway)

Access control

The only things you have to set up is access control, under 'Select Remote Users'. Administrators are always allowed, and if you want to have regular users log in, you have to add them here. If, incidentally, you have a passwordless login, which people do to make their computer start up to their desktop without having to log in - you cannot use that particular account for Remote Desktop. Either you accept that and use another account (and accept that that won't give you the My Documents of your regular user) or you have to add a password to the account.

(The last is done via 'Control Panel', 'User accounts', <click the user>, 'Change my password'. You should do this as the user itself, and not as an admin, when possible.)

Linux client

rdesktop is a good option. Try to get the latest version. With a little option fiddling it should be able to fit most needs, including even thin client pseudo-windows machines.

You usually want:

  • color depth to be high-color:
    -a 24
  • to specify fullscreen -f, or a resolution, e.g.
    -g 1024x768

Also useful:

  • -u loginname
    fills that in in the login. Probably most useful if you create a shell script with your options.

For speed, you can fiddle with:

  • -x m
    disables the background, most fancy animations, etc.
  • -m
    only sends mouse clicks, not motion. Less back-and-forth, but hovering and a few other things don't quite act like it should.
  • -z
    compression - I've not noticed a big difference, though

From an applet

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Go to the properJavaRDP sourceforge page, or rather, the projects' download page.

Then try some howling on a full moon, because I can't get it to bloody work.