FreeNX on Linux

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:
http://fedoranews.org/contributors/rick_stout/freenx/freenx-0.2.7-0.fdr.1.noarch.rpm
http://fedoranews.org/contributors/rick_stout/freenx/nx-1.4.0-0.fdr.3.i386.rpm

For Debian:
By adding the following to “/etc/apt/sources.list”:

deb http://kanotix.com/files/debian/ ./

the running

# apt-get install freenx

  1. 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:
    76:f1:09:07:f3:ef:4d:0a:a9:b7:ac:48:49:93:67:fe falfaro@mac.local

    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.

  2. 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

  3. 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

  4. 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
    quit
    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.

  5. Configuring FreeNX server to support resuming of suspended sessions

    In file “/usr/bin/nxserver”:

    Replace the line that reads:

    ENABLE_AUTORECONNECT="0"

    with

    ENABLE_AUTORECONNECT="1"

    Replace the line that reads:

    session_list_user_suspended "$USER" 'Suspended' "$(getparam geometry)" "$(getparam type)" | log_tee

    with

    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

  1. 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 —knd1983@gmail.com

  2. 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ó
    Un saludo

  3. ¿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).

  4. (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?
    Alguna idea?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s