To give a little background: the GUI under Linux (and Unix) is usually distributed the following way:

• X (the short term commonly used for X Windows System or X11) – this knowns how to draw some primitive elements (like boxes, text, etc) and to get input (from keyboard, mouse, etc) and also has the primitive notion of windows (rectangular, possibly overlapping areas of the screen), but doesn’t know much more than that (it doesn’t know for example about title bars, how to move windows around, etc)
• The window manager (like Gnome, KDE or XFCE just to name a few) which uses these primitives to draw more advanced widgets (like icon lists for example), provide additional functionality (moving around the windows, minimizing / maximizing them, etc) and other graphical elements (panel elements – aka gadgets – for example)

The communication between these two components is done through sockets with a well defined protocol. Isn’t this inefficient? – one could ask. The answer is – not really, because most of the time (more specifically, when X is running on the same machine as the the window manager, a special kind of socket is used called Unix domain socket. These look like normal sockets in the sense that data I/O is represented by a stream of bytes and it has similar guarantees to TCP (guaranteed, in-order delivery), but is optimized so that the data doesn’t have to flow through the TCP/IP stack twice (once at the sending and once at the receiving end) as it would if you would to use a TCP/IP connection to localhost. Windows has a similar architecture where the GDI functions (which are at a similar abstraction level to X – they only know about lines, rectangles, etc) use an IPC (Intre-Process Communication) mechanism to communicate with the Windows subsystem which in turn calls the display drivers.

The only difference between *nix and Windows is that in Windows this modularization was never made explicit and/or documented. This system means that we can execute the drawing instructions on a remote computer (simply by using a TCP/IP socket instead of a Unix domain socket) and we get a very responsive remote deskop for free. It is responsive because instead of transmitting the bitmap that has to be drawn pixel by pixel, it only transmits the primitive instruction needed to draw it (of course there are corner cases, for example if you’re doing image editing with GIMP).

The simplest to use X for Windows is Xming. To set it up you first need to have SSH access to the computer which will be the target (the one actually running the applications). Again, you can observe the modularity present in *nix systems – reuse existing components, which means faster development (because you don’t have to write it from scratch), better quality (because you don’t have to write something which isn’t your core competency) and easier use (because the user can reuse her/his knowledge of the components when configuring different parts of the system). Also, in the case of a vulnerability a central patch can secure multiple systems (there is reverse of this coin of course: sometimes the user isn’t aware of all the dependencies of such systems, which means that s/he can follow the relevant forums for all of them to stay informed about the needed updates).

There is a nice tutorial over at terminal23.net about setting up the SSH daemon under Ubuntu, complete with advice on how to block brute-force attempts and how to restrict access to a certain subset of IP addresses. I would like to add a couple more things:

• You can (and should – defense in depth is a good thing) restrict the access to your SSH daemon from the firewall too. While the temptation is big to leave it wide open because one never knows when I need to access it from an other network, my experience has been that the number of places where one needs access from is very limited. Give /24 (or /16) subnets access if you’re worried that your IP may change (for example cable providers usually have static IP, but they don’t make this explicit, which means that they can change the IP whenever they wish, but it is very unlikely that they will change it outside of the current /24 range). If you don’t want to play around with iptables, you can use Firestarter to do it graphically (sudo apt-get install firestarter).
• If you have multiple interfaces on your computer (which is not as rare as it was some time ago – for example you could have a wired and a wireless interface. Also you can have VPN pseudo-interfaces) make sure to instruct the SSH daemon to listen only on the interfaces where it’s truly needed. You can do this by editing the /etc/ssh/sshd_config file and specifying the correct ListenAddress directives. You could instruct it to listen on a different port (as an additional security measure). If you do so, do not forget to alter your firewall configuration. Also take into consideration what ports will likely be blocked / allowed in the environments you need access from.
• Do not forget to check if there exists a Protocol 2 directive in your /etc/ssh/sshd_config file and no Protocol 1 or Protocol 1,2. The SSH protocol has two versions: version 1 and version 2. Version 1 was found to have some serious security issues and should not be used unless absolutely necessary (legacy equipment for example). Version 2 of the protocol is well supported by all the mainstream platforms and utilities.

When you finish changing the configuration file of the SSH daemon, don’t forget to issue a sudo /etc/init.d/ssh restart from the command line so that it loads the new configuration file.

Now that SSH is in place, go to the client machine and install Xming. The different install files have the following meaning:

• Current vs Superseeded releases – the model of Xming is to make the latest versions available only to donors. The superseeded releases are a couple of minor versions behind (for example the current version is 6.9.0.40 and the superseeded is 6.9.0.28 as of the moment of writing this) but are accessible to everyone. You can check the releases page to see the difference between the versions, but in practice the superseeded version always worked for me.
• Xming vs. Xming-mesa – Xming uses OpenGL acceleration while Xming-mesa uses a software-only method for drawing. Use Xming unless you have specific problems with it.
• Xming-fonts – when instructions are sent to draw text, it includes just the font names, not the actual font definitions. They are contained in this package. An alternative mentioned on the Xming page is to make the originating computer serve up the fonts through a font-server, however I have no experience doing this.

Now that you have everything installed, use XLaunch to create a new session. If your SSH daemon is listening on a different port, as suggested before, you should specify -P [port number] in the additional parameters for PuTTY or SSH field (these parameters are passed to plink, so you can use any parameter understood by it). If you specify a program to run on startup, I would recommend gnome-terminal if the given system is running Gnome. Once it started, you can launch other programs from it. If you launch GUI programs and are not concerned with their output, append a & after the command (for example firefox-bin &) or launch them in a different tab (you can open multiple tabs in gnome-terminal by pressing Ctrl+Alt+T)

Update: On the netnerds I found the following two alternatives to Xming: X-Win32 (download it for here from here) and Cygwin/X. I haven’t played with them though…