'

freenx server without sshd password authentication.

August 1st, 2012 by Andrea Matesi 10561 Views

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:

ENABLE_SSH_AUTHENTICATION="1"
ENABLE_SU_AUTHENTICATION="1"
ENABLE_SLAVE_MODE="0"

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 nx@localhost

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:

login

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): http://openfacts.berlios.de/index-en.phtml?title=FreeNX_FAQ/Server
(how Nomachine NX Server works): http://www.nomachine.com/documents/admin-guide.php
(a complete guide from the ubuntu forum): http://ubuntuforums.org/showthread.php?t=467219
(useful tips): http://ubuntuforums.org/showthread.php?t=449382
(some other useful tips): http://ubuntuforums.org/showthread.php?t=620057&highlight=freenx
(very helpful, even if I have not made custom nx user keys): http://ubuntuforums.org/showthread.php?t=184374
(may be of interest): http://www.felipe-alfaro.org/blog/2005/08/17/freenx-on-linux/
(may be of interest): http://linuxgazette.net/135/knaggs.html

Posted in LINUX, System Administration | 4 Comments »

4 responses to “freenx server without sshd password authentication.”

  1. DaveNo Gravatar says:

    Exactly what I was looking for.

    Thanks

  2. DaniNo Gravatar says:

    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!

  3. DaniNo Gravatar says:

    The same steps described for Windows work for OSX Lion only when using OpenNX client, I could not make it work with the no machine.com client for OSX
     
    I finally downloaded Mac client from opennx.net 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 nx@myserver.com 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.
     
    Regards,

  4. amatesiNo Gravatar says:

    Glad to help you out, and thanks for your input!