Tips on working with FreeNX on a Debian/Ubuntu VPS

The command-line is and will always be the fastest way to administer a remote Linux installation. But whether it’s running a speed test of the server or monitoring AWStats reports only accessible from the localhost, a GUI interface can often come in handy.

The typical recommendation in such cases is to install VNC and a <Insert preferred desktop environment here>. There are a few problems with this:

1. VNC requires you to open an additional port (or two) at your firewall.

2. VNC relies on it’s own user-authentication database and doesn’t support long passwords.

3. Trying to get usable performance out of VNC is a black art in itself.

The smart answer is NX – a remote desktop solution that relies on SSH for authentication, scales to any sort of connection (all the way down to a 56kbps modem link) and supports multimedia and file-sharing support.

I’m not going to talk about how to install NX on Debian/Ubuntu – there are plenty of guides, including this one on the Ubuntu Wiki.

There are a few “gotchas” when it comes to installing FreeNX on a Debian/Ubuntu VPS and it took a while for me to work out the answers. For the reference of anyone else struggling with these problems then, here are my tips:

  • When I use the NoMachine NX Client and try to exit a session, the application seems to “hang”:

One of the best features of NX is robust suspend/resume support for sessions. On a default install of FreeNX however, trying to exit a FreeNX session from the NoMachine NX client doesn’t work. The problem is that a couple of dependencies aren’t included. To fix this, run the following commands:

On Ubuntu –

aptitude install x11-utils

On Debian 5 –

aptitude install x11-utils && aptitude install xterm

Now when you try to exit the session you should see the following dialog box:

xmessage-ubuntu

  • I was told that the NX Client could tunnel sound, but all I get is an error message on my VPS. I was lied to!

Actually the lack of sound is a problem of working with FreeNX on a VPS. You need to install a Sound Daemon – specifically the Gstreamer Sound Daemon. To fix this, run the following commands in Debian/Ubuntu:

aptitude install gstreamer0.10-esd

Once this done, go to System > Preferences > Sound and modify your settings as follows:

gstreamer-sound

Now when you click the Test button, you should hear the soothing sound of a test tone on your local speakers. Note that this isn’t guaranteed to get applications like rhythmbox working and I have no idea on how to go about fixing problems like those. Also keep in mind that the volume control applet will still complain about missing plugins and refuse to “unmute” itself.

  • I’m able to login via SSH, but trying to login via NX fails.

I’ll begin this section with a  big caveat – the fix for this problem does involve reducing the security of your SSH config. Another caveat – this problem appears to be isolated to Ubuntu.

Situation – you have disabled clear text passwords in your SSHD config (i.e PasswordAuthentication no) and only allow Public Key authentication.

Problem – The NX client fails when trying to connect to the Server. If you turn on debug-level logging for SSH, you see the following message in your auth.log:

(nx) Failed login for user=<someuser> from <so.me.I.P>

You know the password for <someuser> is correct and have typed in letter-by-letter 10 times now.

Diagnosis – Tracing the root of this problem is very hard for two reasons – 1) the error message is very generic and can occur in a number of scenarios and 2) It seems specific to Ubuntu. Debian does not require any changes to your SSHD config to get FreeNX working.

Solution – The only solution that I could find after multiple iterations with the SSHD Config is to enable clear text passwords. In other words, open the sshd_config file and change the line

PasswordAuthentication no

to

PasswordAuthentication yes

Reboot the SSH daemon and FreeNX will start working without a hitch.

It is worth noting that enabling PasswordAuthentication does not imply the passwords are sent unencrypted – they are still encrypted using the host key. In addition, you can lock down SSH access to specific users/groups using the AllowUsers or AllowGroups directives in your SSH config.

Comments are closed.