Running X Tool from a Remote Connection

I have been using SSH to connect to my LAN network computers and make all sorts of changes to the machines running in a console and X tools. Works just fine.

Setup the SSH Tunnel

I actually setup the X11 capability with two changes:

1) setup the SSH server with:

X11Forwarding yes
X11DisplayOffset 10

Then restart the SSH server.

2) setup your client with a ~/.ssh/config file where you enter:

Host remote
  ForwardX11 yes

This is the equivalent to the -X command line option, without you having to remember to enter the option every time you connect.

Using the SSH Tunnel

Here we show two prompts. One called "me" and the other called "remote".

The "me" prompt is the computer I'm at. The one where I want to see the windows of the X tools I start on my work computer, also they run on the remote computer.

The "remote" prompt represents the other (remote) computer.

me $ ssh -X remote
remote $ virtualbox &

This works as expected. I can for example open a virtualbox window on my machine, but the tool really runs the virtualbox system on the remote machine.

However, in this way the output (windows) managed by virtualbox are really slow. I'm pretty sure that a great deal of the slowness is due to the SSH encryption / decryption which is totally useless since that's on my LAN network, a fully trusted system.

How can I skip on the Encryption/Decryption of SSH while running virtualbox?

DISPLAY Variable

So, to avoid the encryption and decryption that SSH imposes, I would like to use the virtualbox directly over TCP/IP instead of through the SSH tunnel. I know that X is capable of doing so.

In most cases, you are told that to start a tool on a remote computer running X, you need to setup your DISPLAY variable appropriately. The way to do that is pretty simple:

remote $ DISPLAY=me:0 virtualbox &

Notice that you tell the remote system to start virtualbox and display its windows on the DISPLAY running on host "me" and display zero (0).

However, with most Linux distributions today the default is to prevent such connections so you get an error:

Qt WARNING: VirtualBox: cannot connect to X server: me:0

I tried many different things as the answers I could find on the Internet were not very talkative to me.

There are actually three problems to resolve.

Make sure X11 opens a TCP port to accept connections

By default, in most distributions, X prevents TCP connections for security reasons. You have to make sure it does not get started with -nolisten tcp. If you have an old installation, make sure to check your /etc/X11/xinit/xserverrc file. There is a copy of mine and as you can see, at some point they had that option hard coded on the command line defined in this file. That will prevent other lightdm (or gdm) options from working.

I edited the exec ... line and removed the "-nolisten tcp" option:

#!/bin/sh

exec /usr/bin/X "$@"
#exec /usr/bin/X -nolisten tcp "$@"

Next, with lightdm, you want to make sure it starts with the TCP port. By default it will add the -nolisten tcp option in the $@ variable.

I have seen two locations that can accept the file. The one I used and that worked for me is under /usr/share as follow:

/usr/share/lightdm/lightdm.conf.d/99-custom.conf

The other location is like this (I have not tested that location and thus do not know whether it works, but it seems more logical):

/etc/lightdm/lightdm.conf.d/99-custom.conf

Finally, some people directly edit the default configuration file. That can be problematic if you want your distribution to properly manage the default configurations. (i.e. if you edit this file, then the upgrades will not touch it anymore and you could end up with something incompatible.)

/etc/lightdm/lightdm.conf

The content of the 99-custom.conf file needs to be as follow

[Seat:*]
xserver-allow-tcp=true

Instead of [Seat:*] you may also use [SeatDefaults]. Either one will work in our circumstances. If you only want to share a specific seat, you can also specify that seat: [Seat:0].

This change will allow you to get a port 6000 opened. That port can be used without encryption to connect to a remote X11 server. Note that after these changes you have to restart lightdm. If you are using startx, log out and run startx again. If you are using init 3 (you see an X11 prompt on boot) then just do a log out and log back in.

me $ netstat -a64n | grep 6000
tcp        0      0 0.0.0.0:6000   0.0.0.0:*   LISTEN
tcp6       0      0 :::6000        :::*        LISTEN

Verify that you can connect to port 6000 (firewall in the way?)

From the remote computer, you want to test that you can connect to port 6000 of your computer ("me" in my example here.) You may do so with nc or telnet. I like nc because I can just hit Ctrl-C to exit quickly.

me $ ssh -X remote
remote $ nc -v me 6000
Connection to 10.0.0.2 6000 port [tcp/x11] succeeded!

Notice that are are logged in the remote computer to perform the test (i.e. you need the TCP port open on YOUR instance of the X server. If you think about it, it does make sense, but it can be confusing when you first see it.) The result has to be succeeded.

The connection may fail (1) because X did not open the port (see the netstat command example to test that the port is indeed open on "me"); (2) because you have firewall rules on "me" or "remote" that prevent the packet from going through; if you have such a firewall, I suspect you know how to set it up. Just make sure port 6000, TCP, is open for outgoing traffic from your "remote" computer and incoming traffic for your "me" computer.

X11 Permissions

Assuming that you are on a LAN like me (i.e. computers that are sitting around your place of work and not remote computer that are on a server in the Internet), then you can make it very simple on permissions. There are two tools in that area. One is called xhost and the other xauth. I'm not too sure what you have to do (if anything) with xauth. What I have done is open the port to all connections using:

me $ xhost +
access control disabled, clients can connect from any host

The command line option is just one plus (+) character. This allows all connections whatsoever.

Please check the manual pages of xhost and xauth for additional information.

Again, I recommand you use xhost + only if you trust your network 100% because otherwise one can run any X windows on your computer. (in most cases it is rather safe, but I do not know of all the things you can really ask X about... whether it can run as an RPC?)

Notice that the permissions are on your computer, not the remote computer. Although you can always run it on both.

I looked into xauth but I have not really got that one. I have not added anything to the definitions of xauth and opening windows works as expected, so I guess you can ignore it unless you really need high level authentication of some sort.

Finally, we can start virtualbox ignoring the SSH tunnel

Now that we have this working as expected on both sides, we can try that command with the DISPLAY variable again and it will work:

me $ ssh remote
remote $ DISPLAY=me:0 virtualbox &

This time, no errors.

The -X and -Y are probably not required on the ssh command line (since I have a setup in my config file and was too lazy to comment it out, I do not have a definitive answer on that one.)