I think the best method to securely access remote X sessions is with the NX Protocol. It does delegate the auth to the good 'ol openssh server, then wraps all up and sends back-and-forth graphics goodness between two proxy hosts.

My scenario is the following:

1) a windows xp rig.

2) an ubuntu lan host with freenx server and openssh server.

For security reasons, I configured  openssh without password authentication and allowed only certain users.

I decided this config was good enough for me, 'till the day I found problems with freenx.

The problems I found where key-related; practically, when trying to authenticate with the nomachine freenx client, I received the following message:

"DSA key is corrupted or has been protected with a passphrase"


After some trials, I encountered a LOT of error messages and made a hell of a search to try and understand what those error messages meant.

I activated the logs on the freenx server side and saw what was happening on real time while trying to connect, then I tried to understand what those errors meant and why they appeared.

In the end, I found and applied some suggestions I found from the mailing lists, from the ubuntu forum and even from some manuals (even if I am too lazy to read them...). Finally I made it working like it was (perhaps) intended to!

To make things shorter (and spare you some error messages debugging and interpreting), here are some configurations tips I implemented on my /etc/nxserver/node.conf:


I am assuming you do not have an X server running (in fact I am using an ubuntu server install with the package ubuntu-desktop post-installed and disabled from runlevel 2), but to be sure, you can "/etc/init.d/x11-common stop" and "/etc/init.d/gdm stop".

Then I went on my / and checked the /tmp permissions: they were wrong, because none other than root could have written there, so I relaxed my permissions(!), allowing others to write on my /tmp (well...777 recursively, but this is my internal home server). Another problem I found, was some remnants inside my /tmp, and specifically there was a hidden file named .nX1001-lock or something similar.

Another thing I took care of was to add the nx user on the allowed ssh users, so I added "nx" inside the sshd_config file, followed by a space and by my user.

I also made sure to clean some old sessions remnants, so

nxserver --cleanup

If I wanted to know the freenx server status, I written:

nxserver --status

If I wanted to restart it:

nxserver --restart

There were two places to look at when diagnosing for troubles: /var/lib/nxserver and my user's .nx folder inside my home (/home/username/.nx); I searched those folders for clues of wrongdoing.

Another important thing I have done was to correctly setup nx user's keys, so I appended "authorized_keys2" inside my user's own .ssh/authorized_keys like so:

cat /var/lib/nxserver/home/.ssh/authorized_keys2 ~/.ssh/authorized_keys

To allow the nomachine client from windows to work, I also copied the /var/lib/nxserver/home/.ssh/client.id_dsa.key inside my windows pc, I then configured the client for it to use such key (look for it on the advanced tab).

A very useful method to diagnose possible problems was me talking personally to the server; so I opened a terminal on my ubuntu server, went on the freenx .ssh home (cd /var/lib/nxserver/home/.ssh/) and from there launched a ssh session by using the client key like so:

ssh -i client.id_dsa.key [email protected]

this command would have opened a session to the local server; I then inputted commands like I was a client, for the sake to figure out what was wrong. I used the  following commands:


startsession with a ton of parameters

[some hours later...]

Finally, after having applied all of this modifications, I started the gdm daemon (/etc/init.d/gdm start), and I was able to connect to my freenx server without a hiccup from my windows xp. Was it worth it? I think it was, but no as much as to keep you asleep for one night!

Some links:

(official freenx wiki):
(how Nomachine NX Server works):
(a complete guide from the ubuntu forum):
(useful tips):
(some other useful tips):
(very helpful, even if I have not made custom nx user keys):
(may be of interest):
(may be of interest):

Senior Professional Network and Computer Systems Engineer during work hours and father when home.

Andrea strives to deliver outstanding customer service and heaps of love towards his family.

In this Ad-sponsored space, Andrea shares his quest for "ultimate" IT knowledge, meticulously brought to you in an easy to read format.

freenx server without sshd password authentication.
Rate this post

4 comments on “freenx server without sshd password authentication.

  • Man! Exactly what I was looking for too.
    I have followed your instructions and I can now use freenx in Ubuntu with a Windows client.
    I am struggling too with a MAC Lion NX client but I am convinced  some of the changes you list here will help to achieve that too (pending to validate)
    Thanks again!

  • The same steps described for Windows work for OSX Lion only when using OpenNX client, I could not make it work with the no client for OSX
    I finally downloaded Mac client from and after configuring it using the same client.id_dsa.key (advance setup  and import) I managed to make it work. 
    From MacOSX it is notably slower though than my experience from Windows client.
    Trick: although my SSHD configuration in my Ubuntu does not permit user and password (only based on keys) the UI client still asks for user and password. I had to enter my credentials although I do not quite understand yet why I am forced to provide them and I do not have to when enter the ssh -i client.id_dsa.key [email protected] from an iTerm2 session in my MacOS and it works...
    Anyhow, I have now something else to worry about, Thanks again to the author of the original post that provided so important hints.

Comments are closed.