Running X Tool from a Remote Connection
Setup the SSH Tunnel
I actually setup the X set with two things:
X11Forwarding yes X11DisplayOffset 10
Host remote ForwardX11 yes
Using the SSH Tunnel
Here we show two prompts. One called "me" and the other called "remote".
me $ ssh -X remote remote $ virtualbox &
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.
|Note:||I use & after virtualbox so the tool runs in the background. That way I can continue to run other commands in the same shell.|
How can I skip on the Encryption/Decryption of SSH while running virtualbox?
remote $ DISPLAY=me:0 virtualbox &
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.
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:
exec /usr/bin/X "$@"
#exec /usr/bin/X -nolisten tcp "$@"
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:
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.)
The content of the 99-custom.conf file needs to be as follow
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.
To check that you have the TCP port open, you may use the netstat command as in:
me $ netstat -a64n | grep 6000 tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN tcp6 0 0 :::6000 :::* LISTEN
The port is nearly always 6000. If you changed it, obviously, search for the port you specified.
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.
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:
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?)
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
me $ ssh remote remote $ DISPLAY=me:0 virtualbox &
This time, no errors.