NoMachine NX 3.0 improves remote access to Linux boxes

NoMachine recently released version 3.0 of its remote desktop product line. NX 3.0 has some interesting advantages over similar products — but also some pitfalls for inexperienced users.

You can download several varieties of NX software from nomachine.com. Lacking prior experience with NX, I initially found the product matrix confusing: there are free downloads for NX Free Edition, NX Server, NX Node, NX Client, NX Server Manager, NX Web Companion, and NX Builder. The FAQ linked to at the top of the page was unhelpful, and the product pages described how great all of the products were without addressing how to get started.

I eventually got the hang of things through reading installation instructions and tutorials written by other users on various third-party Linux discussion forums. The upshot is that you need to install an NX Server, NX Node, and NX Client onto each Linux machine that you want to access remotely, and a copy of NX Client onto each machine (Linux, Mac OS X, Windows, or Solaris) from which you want to do the accessing.

For the NX Server component, you have multiple choices. NX Free Edition is properly called NX Server Free Edition; it is the zero-cost option. The other editions of NX Server are commercial; a comparison page outlines the different features available. NX Server Free Edition limits you to two concurrent NX sessions and two NX-capable user accounts (which can be regular accounts on your Linux box, or accounts that you set up just for NX access).

NoMachine provides binary packages for an impressive array of Linux distributions: Red Hat, Fedora, openSUSE, SLED, Mandriva, Xandros, Debian, and Ubuntu — supporting multiple releases of each — and tarballs that should work on other distros. For those distros with an AMD64 version, both i386 and AMD64 architectures are supported. Download the packages, then install first nxclient, then nxnode, then nxserver.

NX tunnels over SSH, so you need to have a working SSH server on your host machine. NX Server and NX Client are each distributed with one half of a public key pair. This key is only used by the “nx” user account during session establishment — after the connection is made, actual login is done via a standard Linux user account. Still, you need to either make sure that the default NX key (in /usr/NX/home/nx/.ssh/authorized_keys2) is added to your /etc/ssh/sshd_config file, or generate your own key pair and use it instead. Generating a new key yourself will buy you extra security, since the default NoMachine key — much like a default password — is a known quantity.

When you are just starting out, I recommend sticking with the NoMachine-supplied key. Though you can learn how to create a new key pair from the OpenSSH documentation (and probably from your distro), it makes little difference whether you take that detour or not — whichever key pair you use, NX functions exactly the same.

Connecting

Once everything is installed, start the server by running sudo /usr/NX/bin/nxserver –status, and look for any error messages. Once the server is running, you can connect to it from a client on any other machine.

With the VNC remote desktop application, you can connect to a session on any remote machine on which VNC runs, be it Linux, Unix, Windows, or Mac. But NX is a one-way street. NX Clients are available for other platforms, but NX Server runs only on Linux — you cannot use NX technology to connect to a remote Windows box. This is because NX works by compressing and relaying the X Window session itself. The tradeoff is that, by giving up cross-platform operation, you gain considerable speed over a lower-level remote technology like VNC and its Remote FrameBuffer.

Connecting to the NX Server machine is easy. The Mac and Windows versions of NX Client have GUI launchers. The Linux client package should install several .desktop launchers (although you may not see them in your applications menu until the menu reloads). You can also launch the client from the command line with /usr/NX/bin/nxclient.

The NX Client Connection Wizard both steps you through your first session and saves your preferences for future reuse. To connect, all you need is the IP address or name of the machine running NX Server and a valid account on the machine. If you want to connect to the NX Server machine while logged in locally (as I did when testing NX initially), be sure that your user account is permitted to make multiple logins (mine wasn’t).

Once you do log in, you’ll have a full X, GNOME, or KDE session running on your client machine. Everything accessible to you if you were logged in locally is available through the remote connection. And performance is fast; there was little to no lag time between mouse clicks and screen updates in my tests — something that I can’t say for VNC.

Sound was a little bit pickier; I was able to get standard music players (such as Rhythmbox) to work over the remote connection when using the Linux client, but not when using Mac OS X. And only apps that can use the Enlightened Sound Daemon (esd) for their audio output on the server side work — others, such video4linux apps, produced no sound on any client.

Among NX 3.0’s many options, I found it odd that the default setting is to disable SSH encryption for the session data itself — encryption is still used during authentication, of course, but not for regular traffic. With encryption turned off, I had trouble getting a session established, even over a LAN with no firewall. The authentication step would complete, but about half the time, a session would time out while downloading the first screen of data.

I also had my share of hangups during remote sessions. I don’t expect perfection when it comes to remote X sessions — hangups are a fact of life, and VNC and RDP are just as susceptible. But I was disappointed in the lack of error reporting in NX 3.0. Every NX session creates log files in ~/.nx, but none of them recorded any errors, not on connection timeouts, crashes, incorrect logins, or any other situation. When I am working over a remote connection and things head south, I would like to know why; if that information is stored anywhere (including under /usr/NX/), I couldn’t find it.

NX is capable of more than just simple remote X sessions. It can tunnel both VNC and RDP, and you can set up “shadow” sessions, where remote users can watch, but not interact with, an X session on a remote machine. Paranoiacs will be happy to learn that NX notifies you when a remote user starts shadowing your session, and that you can disable shadowing altogether.

Business users have a lot more options in the NX Server column than do freeloaders. The commercial versions of NX Server allow greater numbers of NX users, and more concurrent connections, plus niceties like user profiles and management of multiple NX Servers from one place.

Conclusions

As a whole, I found NX 3.0 to be very capable software, and faster than VNC, which for a free solution is reason enough to earn a place on my network.

Of the pitfalls that ensnared me as I got started with NX, what really bothered me was how difficult it was to find answers. Support (for the free edition) is limited to NoMachine’s online knowledge base and trouble ticket system, which could use more work for the “new user” segment, or at least something to which users can contribute, such as an open discussion forum. But if you can commit time to learning the ins and outs of NX, the returns are valuable.