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_configfile and specifying the correct
ListenAddressdirectives. 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 2directive in your
/etc/ssh/sshd_configfile and no
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 18.104.22.168 and the superseeded is 22.214.171.124 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
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…
6 responses to “Setting up Xming or RDP equivalent for Linux”
I was reading through this and saw a link to me! Yay! 🙂
I like your additional tips. In fact, I plan to (someday, yeah I know) get port knocking on the SSH server. That should make me happier about leaving it open to the world.
It’s not quite so simple. RDP support connecting to an *existing* desktop session running on the remote machine, without having to start a whole new shell. Similarly, the session can be disconnected and rejoined at the local terminal, without terminating all the applications that (in X terms) were connected to your local X server.
To my mind, for all the supposed benefits of the X server architecture (and I think it did provide benefits in e.g. the 80s), the RDP model seems to me far superior to X.
Process works up to the point of opening the command window then only xeyes and xclock work. no gnome.
If by “command-window” you mean “gnome-terminal”, you are already running Gnome (or at least a program based on Gnome). I don’t have any concrete suggestion, but my first idea is to check that you are indeed using Gnome, not KDE.
If you wish to get the complete desktop, not just individual applications, you can do this by selecting “Fullscreen”, “One window” or “One window without a titlebar” at the first step of the connection configuration (in essence any option other than “Multiple Windows”) and at the second step select “Open session via XDMCP”.
also to get your linux screen to show up use the command gnome-session. it shows your linux desktop and all. make sure you have all your setting configured and that you have the xming-fonts located someonewhere
Here is another alternative to xming