After years of enjoying the ease of remote server management using Remote Desktop/Terminal Services in the windows world, I was kinda disappointed with the out of the box remote server management options included with most Linux distributions. Sure, you can do a lot of remote admin stuff through the command line using ssh. The graphical environments for *nix operating systems are after all thin, shell veneers running above a core of command line functionality. Linux seems to have a command line tool for everything, if you can remember them all and their syntax (though you can certainly just look that up). If you know your command line tools, one can build up quite impressive functionality by scripting interactions among them.
I was pretty impressed by Jigdo, short for “Jigsaw Download,” which is one of several ways you can download a Debian CD install image. Rather than download a big iso, Jigdo goes out and fetches all the individual packages from mirror sites, does checksums on all the parts and then assembles all the parts into an iso image that is identical to what one would have downloaded as one big file. This is a bit like bittorrent, except Jigdo is just a scripted conglomeration of common Linux tools like wget. Anyways, my original point before I digressed was that there are a lot of instances where ssh for performing common tasks is just going to take longer than using a gui. So, what are the remote gui options in Linux?
The first option is to use a X client on your local machine to connect to the X server on the remote machine. This requires one to have a X client installed on your local machine, which is a non-trivial task with some operating systems. One also needs to configure the X server at the remote end to allow remote connections. In addition, X is not secure, so one should be tunneling it over ssh anyways. In short, accessing your remote server is going to be a bit of a pain, particularly if you are using some random computer as the client.
With Microsoft’s Remote Desktop feature, one can access a remote server from most newer computers simply by typing mstsc in the run dialog box (Microsoft Terminal Server Client). On Microsoft computers without the client, particularly older Win98 machines, one can still access the remote server by launching IE and pointing it at a web server serving up the “Remote Desktop Web Connection” active-x control. Even if you can’t (or won’t) pop open IE to load a remote desktop client, most non-microsoft OSes these days are shipping with remote desktop clients build in, including most Linux Distros. So, it is pretty easy to access a Microsoft OS running server from almost any OS. Going the other way is not quite as simple.
The logical thing for a Linux distro to do to enable cross-platform remote administration abilities would be to include a VNC server. VNC was originally developed at Olivetti research labs, which was bought by AT&T. At its simplest VNC server encodes the video frame-buffer and sends it to the client, while the client can send key presses and mouse events back to the server. The basic protocol is well documented and open source. While many variants exist, most VNC software maintains backwards compatibility, so almost any client will work with any server and vice versa. VNC clients and servers are widely available for almost any platform. One could easily carry around clients for every major OS on a USB flash drive. Most VNC servers also contain a small web server which can serve up a cross-platform JAVA client to virtually any platform with a web browser. Debian and Ubuntu both include a VNC server called Vino, which is easily enabled. Vino suffers from a number of problems which makes it unacceptable as a remote access solution.
- Vino has very few configuration options, at least through the gui configuration menu.
- Vino has low quality (bit depth) video and laggy cursor response, even on a high bandwidth connection
- Vino only allows connections once an X session has been initiated. It will not connect to the user/session selection menu. One can get around this issue by logging in a user automatically at system start, but that becomes a real issue when mixed with the next problem.
- Vino will only run as the “local console” session. Thus unlocking the server for anyone with physical access and allowing them to see what you are doing. Far from ideal in mixed-hosting data center. Of course, if someone has physical access to your box, they can probably get into it anyways, but one shouldn’t make it easy on them.
- Does not appear to serve up a JAVA VNC client. Older clients that I tried to use could not connect. Most VNC server software will have proprietary extensions, but will be able to fall back on older versions of the protocol standard. Big thumbs down on this issue.
One can solve many of these problems by installing and configuring your own VNC server. There are some good step by step instructions as to how to go about doing this on Ubuntu here. This alternate method for VNC based remote access isn’t perfect, but it is a fair sight better than Vino.
- Fast, high quality server with lots of options
- Lets one to log in to the user selection screen, allowing one to pick the user and session type (Gnome, KDE, XFce, etc.)
- Starts as other than local console, so nothing is displayed on the remote server’s monitor.
- One can start a program, disconnect from the vnc server and log in latter and still have it be running. With Vino, to allow apps to persist between sessions, one would need to leave the server sitting there with the local console unlocked. Its a bit like Screen for X. One potential downside to leaving a session open is that a potential attacker would only have to brute force/find the VNC access password to gain access to your still running session. So, it is probably a good idea to enable a password protected screen saver or something when you disconnect.
- I don’t believe this particular VNC server is overly secure, so it is probably best to tunnel your sessions over SSH as well.
All in all, the remote management options for Ubuntu, out of the box, are a little disappointing. I have a feeling that being a stickler for licensing issues is holding Ubuntu back, on this point. Maybe we would all be better off if Prof. Farnsworth had invented the Finglonger?