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.