It is possible to run X applications remotely. It is even possible to run a linux desktop remotely using VNC. Both are security concerns. Although it requires some setup, there is a fairly easy way to use ssh to secure either an X application or a remote desktop session. It involves X11 forwarding.

Understanding (and explaining) X11 forwarding is confusing. (This is my third rewrite of this page!) To clarify the issues and terminology, let's look at a simple common situation:

Suppose I have a linux machine at home (the local machine) and I would like to run a control panel on another linux machine (the remote machine). I simply ssh to the remote machine using the -X option, run the control panel using a shell command. The control panel, which is an X application, creates X11 commands, which ssh forwards back to the local machine. There the X server draws the window for me and I can interact with it. Simple. We have been doing this for some time.

This is not so simple when we really explain what is going on and try to clarify the terminology:

You can even add 'hops' to this sequence, allowing you to ssh through several machines, run an X application on the final (remote) machine, and forward the X11 commands back to the original (local) machine to display. Nice. Of course, for this to work, you must run an X application on the final (remote) machine and the initial (local) machine must be running an X server.

This raises some security concerns, however. And these security concerns require a bit of configuration.

X11 forwarding and Security Concerns

If you give the -X or -Y option to ssh, any X11 commands that the remote X client issues are transmitted back to the local machine through ssh (but there is a bit of configuration on the remote machine as well, as indicated below.) If the local machine can understand X11 commands (either by running its own X server or by emulating an X server), the X window will appear.

As just indicated, there are two options for forwarding X11 commands through ssh: -X and -Y. This requires a bit of explanation that involves X11 security, which is a subject that I (and we) neither want to nor have time to understand fully. I will try here to explain it as well as I understand it:

X11 servers normally run as root. Normally, you run a client program as you and it contacts your [root] server to display the graphics. As always, a root user on your local machine can monitor your traffic. You are always at the mercy of your local root user, and you are only as secure as they are trustworthy. (In this discussion a 'root user' is any user who can bypass the permissions given to your X authorization database (I assume this is the ~/.Xauthority file))

There is an interesting difference when you run an X client program on a remote machine and it contacts your [root] server on your local machine to display the graphics. This opens the door to a root user on the remote machine co-opting your X session and intercepting the data. This would allow the monitoring of such things as keystrokes. This  open pathway between the client and the server, which normally occurs on the local machine, raises a real issue when it is between two machines, as you may not know the root user(s) on the remote machine, nor have any reason to trust them. (Remember, the traffic between  the machines is encrypted, but the data on either end is not.)

For this reason, some restrictions may be placed on the operations a forwarded X11 program can use. These restrictions are intended to deny the most damaging operations (such as keystroke logging), but they also may keep your X program from functioning correctly. These 'X11 Security Protocols' are placed on 'untrusted connections'. You forward an untrusted connection using ssh -X.

If you know you can trust the root users of the remote system OR must run a GUI program that will not function without full X11 functionality, you can forward a trusted connection using ssh -Y. Thus use of -X or -Y when you are initiating a connection effectively gives the remote system permission to monitor your X connection. [ As I understand it, the only "monitoring" that can occur is of the traffic of your session, so this permissions is left under your control, but this is not completely clear.] If the local system is yours and you habitually want to use -X or -Y, you can specify that either option is on by default by setting the ForwardX11option to yes (turns on -X for all connections) or the ForwardX11Trusted option to yes (turns on -Y for all connections) in ssh's configuration file, ssh_config.

If you really need to run a forwarded X11 window from a suspect remote system, one possibility is to use Xnest. Xnest is an X server that runs as an unprivileged user (an X server that runs under the real X server). It then requests services from the real X server. This means that even if the connection is co-opted on the remote system, the process (X server) it leads to is unprivileged, and is not in direct control of hardware devices. Of course, this additional level of server slows the connection considerably. It was marginally usable on my (20MBit) broadband connection.

Xvnc

Creating your session

You can use X11 forwarding thru ssh and Xvnc to run your server's desktop on your client machine. This procedure is slower than running VNC directly, but it does not require opening up the VNC port on the server, as both server and client processes are running on the server and the X application is simply forwarded back to the client through ssh. The procedure is fairly straightforward. Here's a simple way to get started.

1. Log on to the server. You can logon at the console (easier) or using the command-line remotely. Check that X11forwarding is set to yes in /etc/ssh/sshd_config. and one of the ForwardX11 options must be set to yes in /etc/ssh/ssh_config. All of our machines (including hills) should allow X11forwarding.

2. ensure that the binaries vncserver and vncviewer are found. If either vncserver or vncviewer is not installed, run the following command as root

yum install tigervnc tigervnc-server

3. on the server, create a vncserver instance using

vncserver :2

We will select :2 as our X-display to keep track of it easily. If you dont specify the X-display number, vncserver will use the next available and tell you what it is. You will have to substitute it in the following commands instead of :2

You will be asked for a session password. It will create the session. Remember the password and the X-display number.

5. All we need to do later is to connect to it using the session password and X-display number.

Connecting to your session

If you are at the console of the server you can now test your vnc session by starting the viewer and seeing what it looks like. (If you are doing this remotely, read it anyway)

vncviewer :2

You will have to enter your session password. What you will find is that the entire desktop does not display. This is because the dimensions of the session defaults to 1024x768, which is probably smaller than the current resolution of the display on the server. To get the entire desktop you will have to give vncserver the -geometry widthxheight argument when you create the session. Here's what you do

1. disconnect from the session by closing the window. This preserves the state so that you can continue the session later. (We will be killing this one, however)

2. kill the session using vncserver -kill :2

3. find out the dimensions of your display using the display control panel (System->Preferences->Display). It is probably 1280x1024

4. recreate the session with the correct geometry

vncserver -geometry 1280x1024 :2

Now you are ready to connect remotely! Log off of the server when you are done.

Viewing the session remotely

1. Connect to the server with ssh, using X11 forwarding (-X)

2. Run vncviewer :2 to connect to your session.

   The session will display on the client. Assuming you have reasonable bandwidth, the session will be usable. I tried it on a DSL connection with fairly slow upload speed (330kbits) and it worked, but crawled. (But noone in their right mind would run a VNC application with this low bandwidth. It's amazing it actually worked.) Using a cable modem with 2Mbits upload it was reasonable.
   

3. Close the window to disconnect the session. The session is still active. You can connect to it later.

4. Note that your vncserver process will continue to run unless you kill it. Remember, the only thing that is preventing access to your desktop now is knowing the [probably simple] password you set on your viewer! You probably want to kill your vncserver session! (If you want to have access to a desktop from a remote location you could create a vncserver session for a special vnc user. This would allow you to connect, access the system menus, but not change your personal preferences or have permissions to your data!)