Remote Viewing-Not Just a Psychic Power


Most people today are used to having a nice, intuitive graphical environment when they sit down to use a computer. Gone are the days of using a DOS machine or being lucky enough to have a dial-up account at 300 baud on a UNIX mainframe. Today, most people expect to be able to point and click their way to work nirvana, even when that work is being done on some other machine over a network. In this article, I look at some of the available options, what the relative costs and benefits are, and hopefully by the end, you should have enough information to make a choice as to what would be the best option for you.

Before I begin though, I probably should take a look at what actually is involved in using a GUI on Linux. The overwhelming majority of Linux users will be using the X11 Window System (typically shortened to just X11). X11 has been around since 1987. Since then, it has gone through several revisions, and it's currently at R7. Any X11 installation you are likely to encounter will be some version of X11R7. There have been attempts to replace it, including Wayland, Berlin/Fresco and the Y Window System, but they are fairly rare out in the wild, and you'll need to go out of your way to run into them.

X11 is built on a client-server model. In this model, the X11 server is the part that actually draws on a physical screen. As such, it is the part you end up running on your desktop in front of you. The client portion in this model is the user-space program that has output that needs to be seen by the end user.

Figure 1. The X11 Window System (from Wikipedia)

The client does this by sending requests to the X11 server. These are high level and of the form "Draw a window", "Add text to the window border", "Move the window to the right by x pixels". Because of this, there potentially can be a lot of communication if a lot is going on.

When most people experience X11, both parts of this model are running on the desktop in front of them. But, this isn't the only option. There is no reason for the client and server to be on the same machine, or even on the same continent. Because everything is done by sending messages, those messages easily can be sent over a network connection.

The first thought that should come to you is "Hey, I can open a window on my friend's machine and display rude pictures there." Unfortunately, the writers of the X11 specification have beaten you there and closed that particular hole. By default, X11 servers are configured not to accept connections from clients on the network. You have to allow this explicitly. You can use two separate mechanisms to allow external connections. The older one is called xhosts. With xhosts, you tell the X11 server to accept connections from the servers that you permit. The command looks like this:

xhost +111.222.333.444

The newer authentication mechanism is called xauth. In this method, the X11 server creates a cookie that is required in order to connect to the X11 server. If you want to connect to the X11 server from a remote machine, you need to copy this cookie over to the remote machine. An example of doing this, from the xauth man page is:

xauth extract - $DISPLAY | ssh otherhost xauth merge -

This command pulls out the cookie for the current X11 server and "SSHes" it over to the remote machine and merges it into the user's xauth file.

Once you have done this, how do client applications go ahead and connect to your X11 server? All programs that run under X11 accept certain command-line options. One of these is -display. With this option, you can tell your client program to which X11 server to connect and send its output. The general form of this option is:

-display hostname:display#.screen#

The reason for all of the parts of this option is that a given machine could be running more than one X11 server, and each server could be running more than one display screen. The first server and screen is labeled as 0.0, so in most cases you will use:

-display hostname:0.0

As an aside, you can do this on your desktop. If you open a terminal, you can run an X11 client program with:

-display :0.0

and it will show up on your default desktop.

A consequence of this is that you need to have a connection to the remote machine that will be running the client program. Most times, this connection will be over an SSH connection between your local machine and the remote machine. Luckily, SSH provides the ability to tunnel X11 traffic over your SSH connection for you. This tunneling happens "out-of-band", so to speak. You start a session by SSHing in to your remote machine and using either the -X or -Y options. The -X option is the preferred method. It sets up a secure X11 socket on the remote machine using xauth as the authentication system. Unfortunately, some X11 servers have a hard time with this, so you can use -Y. This essentially turns off any authentication. It is equivalent to using xhost +.

Once your SSH connection is established, a new X11 socket is created on the remote machine, and the environment variable DISPLAY is set to point to it. From here on, any X11 applications you start on this remote machine will send their output to your X11 server on your desktop. When you do this, you may notice something. In most cases, it is unbelievably slow—even slower than slow if the machine you are connecting to is any appreciable distance away. Due, in part, to this issue, the SSH developers have included an extra option, -C. This turns on compression of the data traveling over the SSH connection. A side effect is that the packets being sent containing the X11 protocol instructions get bunched together and sent as a single unit. This makes much more efficient use of the bandwidth available, because you are cutting down the amount of control data that also gets sent over the line.

As I mentioned above, both X11 and X11 over SSH are notoriously slow. In some cases, it is nearly unusable. Luckily, there's another option available, VNC. VNC also follows the client/server model, but it reverses the location of the client and server from what you might be used to with X11. With VNC, you run a server out on the remote machine and then use a client on your desktop in front of you. You can run a VNC server in the background, where it sits and acts like any other service. It also doesn't use any of the standard X11 sockets, so it will not interfere with any standard X11 desktop that also may be running on the remote machine. Because it runs as a service, it can continue to run, whether you are connected to it or not. You can think of it as a GUI version of the old standby, screen.

There also are client applications for all the major operating systems, and they are much lighter weight than a full X11 server. So, you can start up vncserver on the remote machine, connect to it from your Windows box, start some long-running process, disconnect and go home, and then check on its progress from your Linux box. This is a great improvement over straight X11. Also, you will notice that in most cases, it is a bit more responsive than X11 was. This is due to the amount of information being sent back and forth between the client and server parts of VNC.


Joey Bernard has a background in both physics and computer science. This serves him well in his day job as a computational research consultant at the University of New Brunswick. He also teaches computational physics and parallel programming.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

NoMachine tops them all

Anonymous's picture

I've been using NX since about 2005 and there's no other alternative for me. I've also started using their latest preview version for access to Mac. Amazing!!!

X11 and VNC

Radio Online Batak's picture

why are X11 and X11 over SSH notoriously slow? what diffrent VNC?

try Ulteo

Anonymous's picture

It's a very nice application delivery solution.

cannot open display

Anthony Lamus's picture


Somehow I can't make this work with xauth... The only way around it I found so far is to "ssh -X" instead..!

anthony@XXXX:~$ echo $DISPLAY
anthony@XXXX:~$ xauth extract - $DISPLAY | ssh tony@localhost xauth merge -
tony@localhost's password:
anthony@XXXX:~$ ssh tony@localhost
tony@localhost's password:
Linux XXXX 2.6.35-30-generic #61-Ubuntu SMP Tue Oct 11 15:29:15 UTC 2011 i686 GNU/Linux
Ubuntu 10.10
tony@XXXX:~$ ls -l .Xauthority
-rw------- 1 tony tony 109 2012-03-16 10:22 .Xauthority
tony@XXXX:~$ touch mytest
tony@XXXX:~$ ls mytest
tony@XXXX:~$ gedit
(gedit:29325): Gtk-WARNING **: cannot open display:
tony@XXXX:~$ gedit -display :0.0
(gedit:29327): Gtk-WARNING **: cannot open display:
anthony@XXXX:~$ su - tony
tony@XXXX:~$ gedit -display :0.0
No protocol specified
(gedit:29431): Gtk-WARNING **: cannot open display: :0.0

Any clue as to why?

Default configuration of /etc/ssh/ssh-config

Jesse Pollard's picture

Then entry ForwardX11 needs to be yes. Comments in the file indicate you may need ForwardX11Trusted set to yes instead.

NX wasn't exactly snappy

Otomobil Haberleri's picture

NX wasn't exactly snappy under those conditions, but it was completely usable. I turned off encryption, since I was using VPN already.

X works just fine.

Jesse Pollard's picture

Even over long distance (I have used X over ssh from a Washington DC site to San Diego California. What counts is the infrastructure.

Ssh also compresses the X protocol. What can slow it down is the multiplexing of streams across a connection. Most X applications have multiple streams (dialog/menu/workspace,...) and depending on how it is written, each independant window gets a separate stream.

The problem with replacements is what they DON'T support. Most don't allow "cut&paste" from a window from one system, to a window on another system.

The other bottleneck is solvable - nearly all toolkits open multiple 3d windows (even scrollbars are composed of a minimum of 4 windows) and each handles the border/background/scrolling independantly. And this multiplies the I/O overhead.

The solution is (of course) more software on the server - I think it should have a "toolkit plugin" that handles most of the overhead, with only the final operation passed back to the application. The common functions (dialog, scrolling, icons,menus) should be handled by the plugin - eliminating the need to pass draw/redraw events/requests over the net. This would also simplify the various toolkits, and allow a more common display presentation.

Right now, the only thing used this way are the "window manager hints" which are handled locally (to the X server).

X Window Service (X, X2, X3, X4, X5, ..., X11)

Anonymous's picture

The X Window system as been around long before 1987. The number after the X is the protcol level. I remember getting color in X back in 1985. Also back in the late 80s there was "shared X" which allowed a user to create a window (the shared X application) and then could put other application windows into the shared X window and other users could view (and interact with their keyboards and mice (which might have 3 to 14 buttons) with the stuff in the "shared X". By the way X came about because of an attempt to adapt "W" (a windowing environment running on an OS called V) which is when it got its networking capability). There are lots of X related standard options (which GUI applications were supposed to handle) which the developers of Gnome and KDE do not honor and (they modified a few of the standard X options such as the geometry).

I am surprised that xrdp has

SDC's picture

I am surprised that xrdp has not been mentioned.

It is fast and works well in environments with a variety of Linux and windows machines as it is compatible with the stock windows remote desktop client and the Linux rdesktop client. Works great for those cases where you need to log into some conference room windows machine with limited privileges and pull a desktop from your Linux box (without installing any client software).

Ease of setup may vary. I never figured it out on gentoo, but it works pretty much out of the box on Debian.

No Machine NX Client with freenx-server

Malcolm Logan's picture

Been using this combo for several years now, No Machine clients for Mac/Win and Linux... as already said MUCH faster than VNC/X-ssh on a LAN and fantastic on big screens...


Greg Holmberg's picture

I've tried VNC and tinyVNC from a machine at home connected to one at work using VPN over cable-modem, and it was really painful. I also tried SSH -C to Cygwin/X, and it was even worse. Really unusable.

NX wasn't exactly snappy under those conditions, but it was completely usable. I turned off encryption, since I was using VPN already.

Over a LAN, it's quite good. Not quite the same as local, but very good. You won't want to watch YouTube over it, or play games, but for most tasks, it's fast enough to use all day, even at very high resolutions. I'm using two 1920x1080 monitors, no problem. I develop software running Eclipse on the remote machine over NX (scrolling through text and so on), and there's no problem.

Another vote for NX.


One more for NX. I've been

Jay Yaneza's picture

One more for NX. I've been using the X11 combo to access my SunOS boxes (via XDMCP), don't know really why those boxes had a UI, some years ago. Shifted over to VNC for some time. Finally settled with NX, and have been using it since.

1 more vote for nomachine

Anonymous's picture

NoMachine(nx) blows away any other remote desktop option for linux. X is klunky over slow connections, as is vnc. NX is fast fast fast and runs using ssh encryption by default. X has served its purpose but it's time to move on. Ubuntu will be abandoning X for wayland soon and most distros will most likely be soon to follow.

+1 on NXServer/Client. Works

Anonymous's picture

+1 on NXServer/Client. Works similar to VNC but is faster and is now easily installed from most repos. I know for sure it is in EPEL and can be a quick yum install of nx and GNOME/KDE/Flux.

No Machine NX - compresses

Anonymous's picture

No Machine NX - compresses the X protocol.

Re: No Machine NX - compresses

jhansonxi's picture

X2Go is better. Uses SSH also.


Rafael Varela's picture

Well, it depends on what you mean by "better".

The fact is that X2go seems to use the same Libraries as NXv3, so I would not expect better performance than NX.

Taken from X2go FAQ:

Is x2go compatible with nomachines NX or freeNX?

No even though X2go uses the same libraries, X2go aims for an even greater integration into the Linux environment. It’s not possible to use NX client to log on to a X2go server and vice versa.

It's much easier to get

jhansonxi's picture

It's much easier to get working. Since it uses SSH it can share the same key I use for other remote access and tunneling.

Re: It's much easier to get

Rafael Varela's picture

It's a nice feature. Yes, in that sense it is better than NX.

No doubt their objective is a better integration into the Linux environment.