FreeNX is based on NoMachine.com NX compression GPL components to allow a fast, graphical remote desktop terminal session for UNIX-based systems. NX uses SSH tunneling to perform authentication and link parameters negotiation.
NoMachine.com has NX viewer clients for Mac OS X and Linux. By default, the nxclient software uses a built-in private key to allow connecting to the remote NX server via SSH DSA public key. When using FreeNX, it’s recommeded to generate a new private-public DSA key pair and iinstall them onto the client machines and the remote NX servers.
The NX server software uses the “nx” user account, configured to allow for public key authentication, which is then used to start up the remote agent and proxy components used by the NX protocol. The NX client starts a remote SSH session against the NX server using this “nx” user. Thus, we need to manually generate a DSA pair key. The private DSA key will get installed into the client, while the public key will get installed into the NX server.
FreeNX can be obtained from the following sites:
For Fedora Core:
By adding the following to “/etc/apt/sources.list”:
deb http://kanotix.com/files/debian/ ./
# apt-get install freenx
Generating the DSA private-public key pair.
We must use the “ssh-keygen” command line tool to create a private-public key pair. For example, by issuing the following command on the client machine:
# ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/Users/falfaro/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/falfaro/.ssh/id_dsa.
Your public key has been saved in p.pub.
The key fingerprint is:
The private key should NOT be protected by a passphrase, as it will be directly used by the NX client software before any authentication is performed.
Installing the private key into the NX client software
The next step is replacing the NX client software built-in private key with the one we have just created. NoMachine’s NX client software stores the DSA private key in “/usr/NX/share/client.id_dsa.key”:
# ls -l /usr/NX/share/client.id_dsa.key
-rw-r--r-- 1 root wheel 668 27 Dec 13:59 /usr/NX/share/client.id_dsa.key
Thus, we should execute the following command:
# mv /usr/NX/share/client.id_dsa.key /usr/NX/share/client.id_dsa.key.OLD
# mv /Users/falfaro/.ssh/id_sa /usr/NX/share/client.id_dsa.key
# chown root:wheel /usr/NX/share/client.id_dsa.key
# chmod 644 /usr/NX/share/client.id_dsa.key
Installing the public key into the NX server software
The last step is installing the public key, which corresponds to the “nx” user, into remote server. The public key will be installed as an “authorized_keys2” file inside the home directory for the “nx” user. The OpenSSH service will use this file to store the “nx” user public key the NX client software uses to authenticate against the NX server.
Depending on the distribution and FreeNX implementation, the home directory for the “nx” user will be located in different places. In Fedora Core, this is usually “/var/lib/nxserver/nxhome”. In Debian, this is usually “/home/.nx”.
The last step is distributing the “id_dsa.pub” file to the remote NX server machine and authorize it:
# scp /Users/falfaro/.ssh/id_dsa.pub root@NXSERVER:
# rm /Users/falfaro/.ssh/id_dsa.pub
# ssh root@NXSERVER
# mv /root/id_dsa.pub /home/.nx/.ssh/authorized_keys2
# chown nx:root /home/.nx/.ssh/authorized_keys2
# chmod 600 /home/.nx/.ssh/authorized_keys2
Testing public key authentication
Before using the NX client software to connect to the remote NX server, it’s recommended to check whether we can connect remotely to the NX server using an SSH client using public key authentication for the “nx” user:
# ssh -i /usr/NX/share/client.id_dsa.key nx@NXSERVER
Linux NXSERVER 2.6.10 #1 Sat Dec 25 05:20:24 CET 2004 i686 GNU/Linux
HELLO NXSERVER - Version 1.4.0-02 OS_(GPL)
NX> 105 quit
NX> 999 Bye
Connection to ubuntu closed.
If this works, we can be pretty sure the NX client will allow us to establish a remote session against the NX server.
Configuring FreeNX server to support resuming of suspended sessions
In file “/usr/bin/nxserver”:
Replace the line that reads:
Replace the line that reads:
session_list_user_suspended "$USER" 'Suspended' "$(getparam geometry)" "$(getparam type)" | log_tee
session_list_user_suspended "$USER" 'Suspended$|^status=Running$' "$(getparam geometry)" "$(getparam type)" | log_tee
This is very important as sometimes, when the NX client is disconnected from the NX server, the session is not marked as suspended.
8 thoughts on “FreeNX on Linux”
Many thanks for the information about resuming sessions! I have amended and updated them for the current version of freenx (but crediting you for the initial information):
Good info… Will multiple users be using same login name”nx”??
say user 1 is aaa, 2 is bbb…. still i need to store the key in .nx/authorized_keys2 ? reply to my mail id if possible —email@example.com
Not sure what you mean. Would you mind to explain?
En la actualidad me encuentro intentando instalar este sistema en una serie de maquinas (con idea de en un futuro no muy lejano de usarlo con diskless thinclient con arranque por PXE)
Me gustaría saber si continuo con los trabajos con Freenx o si desistió
¿Por qué ibas a desistir de usar FreeNX? Personalmente encuentro que FreeNX ofrece bastante flexibilidad. Aunque utilices arranque por PXE, puedes seguir usando FreeNX. Siempre será más eficiente que usar X11, con la ventaja añadida de que usando FreeNX puedes tener clientes remotos (aunque conectados a una red local que les ofrece soporte para arrancar mediante PXE).
(Le hablaba de usted xD)
Bien supongo que podemos tutearnos.
Te cuento la idea…
Supon un cibercafe en el que puedes limitar los programas que usan los usuarios y sus acciones (por ejemplo tener o no internet, determinados servicios, …) todos se conectan a una unica maquina un servidor de xdmcp, al estilo de LTSP, pero en lugar de usar XDMCP o ssh con forwarding (LTSP4 y LTSP5 respectivamente) use freenx, como lo ves ahora?
Hello.This post was really motivating, especially since I was browsing for thoughts on this issue last Wednesday.
Thanks for the info, but you must agree that not everything was mentioned there.