Researching Remote X Sessions

Long Introduction

X was designed with the idea that you could run a session not only on the local machine, but any remote machine capable of serving X. The idea at the time was to have a very capable "server," and several less capable machines with decent displays. These machines would show software that was running on the server, but not do any "computing" beyond what was required for graphics.

These days, individual computers - even the phone in your pocket - have more computing power than was ever imagined for the biggest servers when the X remote display was conceived of. Given that, why would anybody care about this anymore? My short answer is "multiple screens," although the long answer would include mention of "intellectual curiosity." My primary computer is a laptop, and it can only drive two screens simultaneously (either its own and one external, or two externals ... but to my frustration, not all three at once). I have an ancient laptop that has no screen, but is otherwise fully functional - although it's got an old processor and only 768MB of memory. It runs Linux fine, but starts to struggle as soon as you start up Firefox. It drives an external screen fine, why not make it a remote display for my primary?

The common method these days would be to run ssh -XC giles@primary on the secondary and then just run the applications I want. And this works. Better yet, if the two machines are close to each other, I can run ssh -XC giles@secondary x2x -east -to :0.0 on the primary and voila, the pointer slides from one machine's screen to the other and the two have a shared clipboard - it's that easy. So I'm not entirely sure why I'm pursuing this with such ferocity.

The problem is ... no one uses remote X logins anymore. Sure, they ssh -X into another machine, run an application or two - but they don't run a full X session where the machine they're using acts exactly as if it IS the remote machine. Because of this, finding out how to do this at all was tricky. Turns out the protocol is called XDMCP, the "X Display Manager Control Protocol." It is, by the way, totally insecure: all communication is done in the clear over the network. It runs on UDP port 177, and even if I can use ssh's port-forwarding (does ssh handle UDP properly?), I'm not enthusiastic about that because I want both machines to be able to suspend. And with ssh, that would mean having to re-establish the connection every time they wake. Which probably means a VPN, which probably means another article as I figure out VPNs (never used them before: ssh has mostly been enough until now).

LightDM offers a "Secure Remote connection" as one of the session types on the underpowered Debian jessie laptop (interesting that this option doesn't exist on the i7 Ubuntu trusty main machine). Finding out what this actually means is turning out to be nearly impossible: the interface tells you nothing, the lightdm man page tells you nothing, and even Google knows nothing.

Other Options:

  • VNC, X11VNC ... VNC has become significantly fragmented, and I don't know which is "best" at this point
  • lightdm displays a "Secure Remote connection" option that asks for a hostname and port, but doesn't say anything about what protocol(s) are used ... this appears to be totally and completely undocumented, with code diving the only way to find out what it does
  • FreeNX (which is free as in beer, but not speech) - I'd prefer open source
  • Xnest over SSH
  • "Secure Display Manager," aka "sdm" ( , which may or may not be related to ) - this used to be in Ubuntu, but no more: I'm guessing its functionality has been absorbed into GDM, but I haven't managed to establish that yet (and I don't like GDM)

What I've Done So Far

  • change allowed_users=console to allowed_users=anybody in /etc/X11/Xwrapper.config
  • ufw allow proto udp from to any port 177
  • ufw allow proto tcp from to any port 177
  • ufw allow proto tcp from to any port 6000:6010
  • ufw allow proto tcp from to any port 7100
  • although none of the above should be necessary if the ssh tunnel is working, but I can't even get it working without security ...
  • experiment with Xephyr
  • /etc/lightdm/lightdm.conf on the server now looks like this:
xserver-allow-tcp=true         # new
greeter-show-remote-login=true # new

[XDMCPServer]                  # new
enabled=true                   # new
port=177                       # new
  • run the command X -query <IP>:[01] so many times I've lost count