freenx login not working

[simusphere]

Anybody familiar with setting up freenx? I have done it several times with little problem however I tried to fix an anoying issue with some of the desktop applets not working by deleting my user account and starting over. Now no one can login from any account from any client. I've been at this for about three days now and cannot seem to find the solution this problem.

Here is the main error I get while logging in:

 
The NX service is not available or the NX access was disabled on host 192.168.1.100.

After clicking the details button I get:

NX> 203 NXSSH running with pid: 265924
NX> 285 Enabling check on switch command
NX> 285 Enabling skip of SSH config files
NX> 285 Setting the preferred NX options
NX> 200 Connected to address: 192.168.1.100 on port: 22
NX> 202 Authenticating user: nx
NX> 208 Using auth method: publickey
NX> 204 Authentication failed.

More details of the problem:
1. The server is CentOS 5.2 everything is up to date.
2. Client is the No Machine version 3.3.0-3 on Vista Ultimate.
3. Everything was working except some of the desktop applets at first.
4. I backed up my visible files in my home directory and deleted the account. The reason for doing this was because all other users on the system were able to login and had no desktop applet problem. So I was just recreating my user account over again hoping to fix the problem.
5. Tried to uninstall and reinstall the client software.
6. Tried to uninstall and reinstall the nx and freenx rpm packages.
NOTE: I would love to know the proper way to completely unistall all of the software so I could just start over from the begining but some files are remaining persistent after install and leaving the problem intact.

Here is my current sshd_config file:
Note: This is exactly the same config I use on another system that is working just fine.

Protocol 2
SyslogFacility AUTHPRIV
PasswordAuthentication yes
ChallengeResponseAuthentication no
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
UsePAM yes
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL
X11Forwarding yes
Subsystemsftp    /usr/libexec/openssh/sftp-server

Also here is another clue:

[root@linux nxserver]# nxserver --start
NX> 100 NXSERVER - Version 2.1.0-72 OS (GPL, using backend: not detected)
mv: cannot stat `/var/lib/nxserver/home/.ssh/authorized_keys2.disabled': No such file or directory
NX> 122 Service started
NX> 999 Bye
[root@linux nxserver]# nxserver --status
NX> 100 NXSERVER - Version 2.1.0-72 OS (GPL, using backend: not detected)
NX> 110 NX Server is stopped
NX> 999 Bye

This last clue in particular makes no sense to me since the .ssh directory don't even exist on the other system I have that is known to be working. So why is it trying to do this if those directories are not necessary? I have seen lot's of others talking about those directories in other forums or blogs but they don't seem to get setup on the CentOS install of freenx.

I could manually create the directory and cp keys over etc... But why doesn't this get done at install time???? What are the permissions supposed to be on the directory and file if I create them manually?

I would like to keep this as simple as possible and not setup special keys that require each user to have setup before it works. I think the authorised_keys2 file has to do with the special key setup since this file does not exist on the other working system I have and everything works fine on that system.

[simusphere]

More details of the problem:
1. The server is CentOS 5.2 everything is up to date.
2. Client is the No Machine version 3.3.0-3 on Vista Ultimate.
3. Everything was working except some of the desktop applets at first.
4. I backed up my visible files in my home directory and deleted the account. The reason for doing this was because all other users on the system were able to login and had no desktop applet problem. So I was just recreating my user account over again hoping to fix the problem.
5. Tried to uninstall and reinstall the client software.
6. Tried to uninstall and reinstall the nx and freenx rpm packages.
NOTE: I would love to know the proper way to completely unistall all of the software so I could just start over from the begining but some files are remaining persistent after install and leaving the problem intact.

I couldn't find a way to edit my post so...
In #4 above: The main thing I did that seemed to break an otherwise working login using the freenx was deleting my user account completley. I then created a new user with the same name as before and restored my files back to the home directory. Then the trouble started as noted above.

[simusphere]

I ended up figuring out how to get back to broke. Now the login is working but I have the applet problem still remaining. I got the idea on how to get this working by reading one of the tutorials on setting up ssh on these forums. I found out that the authorized_keys or authorized_keys2 file containes the public key. I then ran the following commands to set up the public key for the nx user.

mkdir /var/lib/nxserver/.ssh
chmod 700 /var/lib/nxserver/.ssh
chown nx /var/lib/nxserver/.ssh
cd /var/lib/nxserver/.ssh
cp /etc/nxserver/server.id_dsa.pub.key authorized_keys
cp authorized_keys authorized_keys2.disabled
chmod 600 *
chown nx *
nxserver --start

I have no idea how it works on my other server without these keys in the nx users home directory but it does.

[simusphere]

The problem with freenx, at least the version I am using with CentOS 5.2 and the gnome desktop is old gconfd files in the /tmp directory. For some reason freenx doesn't like any old tmp files previous to the installation of freenx.

Any new users added after the sucessful installation of freenx don't have any issues at all. It's only with users that existed previous to the freenx installation. Cleaning out the tmp files is all I had to do to fix the problem with various gnome applets not working like the desktop switching function or the clock and show desktop icon.

Hope this helps someone trying to install and use the freenx thin client.

[ncswheeler]

I had a few hours of head scratching when freenx stopped working on Centos 5.2 with the same message "the nx service is not available or the nx access was disabled on host" and I tried everything I could find with google and finally I came to your post which inspired me to read the error messages that I got more carefully and then I copied your 'repair' with one addition and some path differences.

mkdir /var/lib/nxserver/home/.ssh
chmod 700 /var/lib/nxserver/home/.ssh
chown nx /var/lib/nxserver/home/.ssh
cd /var/lib/nxserver/home/.ssh
cp /etc/nxserver/server.id_dsa.pub.key authorized_keys
cp authorized_keys authorized_keys2.disabled
chmod 600 *
chown nx *
cd /var/lib/nxserver/db
chown nx *
nxserver --start

nx works fine again now - I've no idea what caused it to stop working and several cycles of uninstall re-install got me nowhere.

[curtis]

A much simpler (and safer) solution to the problem would have been to simply update the RSA key the client uses to connect:

Copy the contents of the /etc/nxserver/client.id_dsa.key file into the "key" data field for your NX client connection to this server and voila...the initial authentication is fixed.

The authentication failure was occuring at the TLS level and has nothing to do with anything else. Simply put, if the keys don't match, you don't get in to even pass username/password information forward. The keys located on the nxserver are uniquely generated(hashed) at every install, which is why your other (old) client key worked with a certain machine and this "new" one didn't. The fix you came up with simply disabled TLS encryption, and thus compromises a level of security. Do you really want to send your authentication information in clear text? I wouldn't - not even at home if I don't have to.

As far as the gnome applet problems, I haven't experienced many problems, nor messed much with it but you seem to have figured it out.

[curtis]

...The keys located on the nxserver are uniquely generated(hashed) at every install, which is why your other (old) client key worked with a certain machine and this "new" one didn't.

(inconsistent wording, so let me rewrite that bold piece) ...not your latest/newer nx server.