HOWTO: Install FreeNX on (K)Ubuntu Breezy
This is my experience in installing the FreeNX server and the NoMachine NX Client on my Kubuntu Breezy.
I had some troubles in getting the whole thing work, so I write this little howto hoping that it may be useful for other (K)Ubuntu users
0. CONFIGURING THE RIGHT PACKAGE REPOSITORY
I used .deb packages from Seveas repository. In order to configure it for apt-get (or Synaptic) add the following line to /etc/apt/sources.list:
In order to install the appropriate gpg key, execute the following commands (as described on the Seveas home page):Code:deb http://seveas.ubuntulinux.nl/ breezy-seveas all
Code:gpg --keyserver subkeys.pgp.net --recv-keys 1135D466 gpg --export --armor 1135D466 | sudo apt-key add -
1. INSTALLING THE SERVER
Having Seveas repository configured, it is easy to install the server part of FreeNX. Simply install the freenx package:
It will also install some dependencies, notably ssh, nxagent and nxlibs. Your (K)Ubuntu will ask you if you want to use the standard NoMachine key, among some other options. I recommend to use the standard NoMachine key for standard use (or for the initial debug of the NX protocol). We will see later how to setup a custom key for higher security.Code:sudo apt-get install freenx
Please note that the key is used for public key authentication on the user "nx", who is used by the NX protocol to establish an SSH tunnel for the secure protocol data transport. Session authentication is (by default setup) based on PAM, allowing server users to establish a remote NX session by mean of their own credentials (username and password, as defined on the server).
It is now necessary to check some settings of the ssh subsystem, by editing the /etc/ssh/sshd_config file:
1) sshd should listen on the standard 22 port. Please check that the sshd_config contains the line "Port 22" and that it is not commented out.
2) public key authentication is turned on. Check the sshd_config so it contains the line "PubkeyAuthentication yes"
3) modify the "AuthorizedKeysFile" line in "AuthorizedKeysFile %h/.ssh/authorized_keys2" (default is "%h/.ssh/authorized_keys")
4) By default, sshd should allow every system user to access the system. If your system is configured differently, please add (or modify) the "AllowUsers nx" line to allow the nx user to access. I think you can use the "user@host" syntax for this sshd parameter to limit hosts from which users can logon via NX.
If you have made any change to the sshd_config, restart the ssh daemon withCode:sudo /etc/init.d/ssh restart
2. INSTALLING THE CLIENT
On the client machine, from the Seveas repository, install the nxclient package.
In my KDE, I found the "NX Client for Linux" in the "Lost+found" submenu. Launching the client for the first time brings up a connection wizard that will allow you to setup a connection to a remote NX server (in this case, the one configured above). Insert the session name (just an identifier of the server/service/host you will connect to), the server IP address and pay attention to check the "Enable SSL encryption of all traffic" option. You may set other options in the connection wizard, for example the type of remote window manager to fire up when the nx user connects (KDE, GNOME, others) and the resolution of the virtual NX session.
Please note that the connection created by the wizard make use of the standard NoMachine key. We will see later how to change the connection key to a custom one.
At the end of the wizard, the NX client logon form fires up. You can insert the username, the password and choose one of the defined sessions.
The login button will attempt the NX connection to the server as defined in the selected session. If you press the "Configure..." button, you can change ALL the parameters of the selected session (the ones defined with the connection wizard and other...).
3. (Optional) DEFINING AND USING CUSTOM KEYS
If you chose "Custom keys" when prompted during the server package, the installation creates a random authentication key for the user "nx". If you chose the standard NoMachine key, you can reconfigure the freenx package to change this setting to "Custom keys" with the following command:
The key is stored in the client.id_dsa.key file in the .ssh subdirectory of the nx home directory (default: /var/lib/nxserver/home/.ssh/client.id_dsa.key). You have to share this key with all the client hosts you want to authorize, by copying this file on the client machine and then importing it into the NX client. The destination path is not important, but you must know it to import the key file into the NX client.Code:sudo dpkg-reconfigure freenx
To import the key, open the NX client, select the right session and click on the "Configure" button. From the "General" tab of the configuration window, click on the "Key" button and then on the "Import" button. Then select the client.id_dsa.key you copied from the server and click on the "Save" button, "OK" button (please confirm to save the new configuration)
From now on the NX connection to the server will use the new key. Clients with the default key (or other custom keys) cannot authenticate to the server anymore.
You can return to the standard NoMachine key by reconfiguring the freenx package on the server, and by modifying the key used by the client with the same procedure described above, but clicking on the "Default" button instead of the "Import" button we used before.
If you played with NX keys and your client doesn't authenticate anymore to the server, you can start from a clean state by reconfiguring the freenx package on the server and choosing the "Remove freenx keys" and reconfiguring again choosing the "NoMachine keys" or the "Custom keys" options.
Conclusions
I apologize for my english, far from being good. However I hope that this howto can help some user that (like me) has encountered troubles in configuring this powerful remote control protocol.
As a last note, if you has other troubles and you have set up a firewall, please check firewall settings keeping in mind that only the port 22 (ssh) have to be enabled in order to establish a connection to the server.
Bye
Adv Reply
Bookmarks