Introduction

This is probably a case of trawling through the archives: I seem to recall writing my first ‘how to do remote X server stuff’ article more than 8 years ago: how time flies!

And how one’s brain atrophies! I’ll confess to having forgotten most of the remote X stuff I ever learnt, which seems a bit of a waste. Happily, however, I happened to have a spare afternoon and thought I’d have a go at remembering most of it all again.

Here, then, are my notes so I can remember it again more quickly next time!

Options

I suppose the first thing to say is that this article describes but one of many possible ways of connecting remotely to a Linux server. At work, I actually use FreeNX and the zero-cost NoMachine NX Client. It’s simple, works well over quite dodgy network links and looks good. One slight problem with it, however, is that it can’t be used to join the root session (i.e., when you connect, you can create a new session; subsequently you can even re-join that new session. But you can’t connect to the very first session that’s already running in the server room, as it were).

Alternatively, you could use good old VNC. Gnome ships with a VNC server anyway (you switch it on by configuring the options in System > Preferences > Remote Desktop), and a client such as TightVNC is easily come by. However, I generally find that the display ‘judders’ and windows tear as they’re moved, even when I’m connecting over Gigabit Ethernet from the PC next door to the server! Over the Internet connection I get from home, the work connections can sometimes be dreadful to use. Moreover, it’s only possible to use VNC to connect to a session that’s already logged in and running the VNC server -which rather defeats the purpose, I think! It means that if you were to hit the Gnome ‘logout’ option whilst using VNC, you’d kill off the VNC server and be unable to re-connect. Not exactly what you want when you’re connecting from home at 2 AM, trying to fix a critical business problem!

Generally, then, I try to avoid VNC-based solutions -though the good news is that ‘console connections’ (i.e., connecting to the main session already running on the server) are do-able, unlike with NX.

Finally, there is “X Forwarding”, which is where all the fun starts! The basic idea is that you run an X server on Windows. Applications running on the Linux box are then told to draw their windows, icons etc. using this new X server. Normally, of course, they draw them using the X server that itself is running on the Linux box. That makes the applications appear to be ‘drawing’ locally, on Linux. Once they know to draw via a remote X server, however, those same applications look to be running on your Windows desktop (complete with standard Windows window decorations, including the Aero transparency stuff you can have in Vista or Windows 7).

This is a lovely feature of X: such networking capabilities have been there since Day 1, are very efficient and run beautifully over poor network connections. In my view, it beats VNC-type connections hands-down for usability (though not, perhaps, in the security stakes… see the start of this article for a good discussion on that).

If you like the sound of X, then, you really only have one question to deal with: how do you run an X server on Windows?

There are various options, including ones you pay quite large amounts of money for. I assume, however, that you’re as cheap as I am, so paying anything at all is a dollar too far! In which case, you could either use the X Ming offering (completely zero cost, standard Windows installer, nice wizard interface to get apps or entire desktops running remotely) or use Cygwin.

Cygwin is completely open source, has a bit of a clunky installer, has no nice wizards to set things up for you and is therefore the somewhat harder solution. On the plus side, however, it’s capable of being far more than just an X server -if you want it to be, it can be an entire Linux emulation layer running in Windows. If you miss being able to do ls or rm when in Windows, Cygwin’s for you!

To be honest, Cygwin is probably overkill for most people needing to do a spot of remote X on Windows: X Ming is all you really need. But I’m going to document Cygwin because (a) it has so many other uses; and (b) it forces you to know what you’re doing, so you learn more. I find (b) makes it the ‘more fun’ approach, in short!

Installing Cygwin

The first thing to do, therefore, is to install Cygwin itself. Again, the software is downloadable from here. That’s only a small ‘bootstrap’ installer, though: once it’s downloaded and you run it, you’ll be taken through a wizard that asks you where you’d like to install it (C:CYGWIN is fine), where you’d like to install the extra packages that you’ll add to it (C:CYGWINPACKAGES works for me) and which server you’d like to get those additional packages from (pick a server that seems close to you, basically).

Then comes the tricky bit: specifying precisely which packages are to be added as part of the full-blown installation. There are thousands to choose from, after all. Happily, for these purposes, you only need to make two alterations to the defaults.

First, click on the Net package group. Find the openssh package in the expanded list and click on the ‘Skip’ option so that it changes to a version number: this means you’ve selected it to be installed:

Ignore the fact that I’ve also selected OpenSSL in that screenshot -that’s just me not reading things carefully enough! You really do just need the OpenSSH programs for now.

The second installation choice you have to make is to scroll down and open up the X11 package group (it’s probably going to be the last one in the list). Find the item called xinit: X.Org X server initializer and again click the ‘Skip’ option so that a version number appears (meaning you’ve chosen to install it):

And that’s it: you now just click [Next] and proceed with the package installation. About 66MB of packages in all will then be downloaded and installed.

Configuring the Linux Box

The Linux box you’re trying to connect to may or may not need some X configuration. I just tested this on a completely default install of Centos 6, for example, and didn’t have to configure a thing. It all just worked out of the box.

So, I’ll just mention this for posterity’s sake (and because you might need to configure it on your particular choice of distro).

First, edit the file /etc/gdm/custom.conf and add the following entries to it:

[xdmcp]
Enable=true

[security]
DisallowTCP=false
AllowRemoteRoot=true

In Centos 6, my file had the headings (the bits in square brackets), but none of the contents… but that didn’t seem to hurt my ability to use X remotely. On the other hand, adding this content to the file didn’t hurt my ability to use X remotely either! In short, it doesn’t do any harm to add this stuff in.

Either way, once that file’s been saved, you should also take a look at /etc/ssh/sshd_config. There should be a line in there which reads X11Forwarding yes: make sure that it’s uncommented (i.e., remove its leading ‘#’ if it has one). Similarly, there will probably be a line which reads X11Forwarding no and that one MUST be commented out, if it isn’t already. As I say, Centos 6, by default, has both lines configured correctly, but your mileage might vary.

Once both files are correct, reboot your Linux box. (Yup, it’s a sledgehammer approach to things, but it’s quick and easy and gets the job done).

Finishing it off

The rest is pretty straightforward, to be honest. First, start the Cygwin X Server (Windows Orb > All Programs > Cygwin-X > XWinServer). You should see an ‘X’ icon appear in your system tray area:

Next, start a Cygwin Bash Shell (Windows Orb > All Programs > Cygwin > Cygwin Bash Shell).

In that new terminal session, you now specify a display screen on which applications should draw their output, and then connect to the Linux box via ssh:

export DISPLAY=localhost:0.0
ssh -Y hjr@oraclebox

(…where “oraclebox” is the name of my Linux box and “hjr” is the username of an account previously created on that machine). Instead of the name of the machine, you could use the IP address, if you preferred:

Notice that you’ll get a warning about “no xauth data; using fake authentication for X11 forwarding“. This is perfectly normal and doesn’t affect functionality in any way (trying to make it not appear involves doing things with the xauth package, and is not for the faint-hearted: chances are, you’ll break more than you fix!)

A Result

So there you are, running a terminal session on your Windows desktop, connected to your Linux box. Commands you type thus execute on the Linux box but their graphical results get painted on your Windows desktop (more accurately, they get handled by the X server which happens to be running on your Windows desktop).

So, by typing the name of an application in your Bash terminal, you cause it to be executed on the Linux box, but its display is re-directed down the ssh link so that it looks as if it’s running on the Windows PC: type a command such as gedit to have the Centos box’s version of that application appear on your Windows desktop, for example:

That’s gedit, a very Linux-y application, being displayed with Aero-effect translucent window decorations on my Windows desktop, complete with various Windows-only programs running in the background.

And that’s the power of X over a network!

If you want to run multiple applications in this way, just stick an ampersand (“&”) on the end of each program’s name as it’s invoked. If you type gedit, for example, then the text editor runs and displays OK, but you can’t type anything else into the Cygwin Bash shell until you close it. If you run the command gedit &, however, then the text editor runs as before but control is immediately returned to the shell: you get back a command prompt you can use to run other programs, in other words. The same thing goes for any other program you can run: firefox &, gcalctool &, evolution & …and so on and on.

What about an entire desktop?

Sometimes, you may prefer to have the entire Linux desktop displayed, rather than individual applications. The approach is slightly different in this case.

The first thing to mention is that to get whole-screen remote X desktop working, you definitely do have to do the X configuration on the Linux box that I mentioned earlier. That means editing /etc/gdm/custom.conf as previously describe -and then rebooting (if you really don’t want to reboot, as root do init 3; then logon as root once more; then do init 5… essentially, you’re just restarting X in a way that parallels what you’d get with a reboot).

Secondly, make sure that you are NOT running the Cygwin X server before you start this. That’s because the command we’ll issue shortly will itself start a fresh X server. If one’s already running when you try that, they’ll conflict and the command will fail. I’ll explain how to sort that out, if it happens, later.

So, assuming you’ve got the Linux box configured correctly and nothing of Cygwin’s is already running on your Windows box, fire up the Cygwin Bash Shell (Windows Orb > All Programs > Cygwin > Cygwin Bash Shell) and issue the following command:

xwin :0.0 -query 192.168.0.42

The “xwin” command starts the X server, on screen number “0:0″, and the “-query” switch is simply making the new X server query what applications on the Linux box require an X server to draw their bits and pieces. That forces a connection to the Gnome desktop manager running on the Linux box, resulting in a full-screen Gnome login window appearing. You can log on there as though you were sitting at the Linux machine itself.

When you do so, you might see this dialog box appear:

I’m not entirely sure why this always seems to appear on first logging on to a remote X whole-desktop session, but it’s perfectly OK to click [Cancel] to dismiss the message.

A nice twist to this approach is that you can ‘window’ the Linux desktop. Issue this variant of the earlier command, for example:

xwin :0.0 -screen 0 1280 1024 -query 192.168.0.42

…and you’ll end up with a ‘whole screen’ Linux desktop, but appearing as a 1280×1024 window on your Windows desktop.

And what about multiple full desktops?

Finally, I mentioned that if you have multiple X servers running on your Windows PC, things won’t work. There’s a workaround for that which, again, involves a bit of back-end re-configuration and then some front-end command-line magic.

On the Linux machine, you need to re-edit the /etc/gdm/custom.conf file and edit the [xdmcp] section so that it reads, in full:

[xdmcp]
Enable=true
MaxSessions=16
DisplaysPerHost=8

The specifc numbers assigned to those two new parameters are a matter for you, of course. The key one is the ‘displays per host’: so long as it’s more than 1, you’ll be allowed to fire off multiple full-screen connections to the one Linux box from the same Windows desktop.

Since you’ve just altered a configuration file, you should reboot your Linux box (or restart X if you are allergic to reboots).

Now for the front-end stuff. Although your back-end will now quite happily allow multiple connections from the one host, each one needs to be assigned a different display number so that each is uniquely identifiable. The display number is the “:0.0″ bit in the earlier command. Increment that each time (to “:1.0″ or “:2.0″ and so on) and multiple whole-screen connections won’t be a problem. For example, if I start 2 separate Cygwin Bash Shells, and type:

xwin :0.0 -screen 0 1280 1024 -query 192.168.0.42

…in one, and

xwin :1.0 -screen 0 1280 1024 -query 192.168.0.42

…in the other, I get this result:

Now, I’m not exactly sure why you’d ever want multiple whole-screen remote X connections to the one server, but the fact remains that you can do it if you really want to!