[Introduction] FreeNX is a free (GPL) implementation of the NX server by NoMachine(!M). By utilizing the products released by !M, we have the opportunity to run remote applications in a way that we have always wanted, but were limited because of bandwidth and design. FreeNX can proxy X11, VNC and RDC connections allowing as much as 10x increase in performance. Full screen connections are easily useable for desktop computing over slow links. [How it works] FreeNX is basically an X session forwarded over an SSH channel. !M has taken and tweaked current remote technologies (X, VNC, and RDC) to allow for faster connections. For example, an X session over a 56k link running at 1024x768 is incredibly fast and useable. This is accomplished by efficient caching, removing the X acknowledgments, and excellent compression techniques. The same compression principles are also applied to VNC (Virtual Network Computing) and RDC (Remote Desktop) connections. The FreeNX nxserver tries to emulate its commercial !M counterpart, and allow the use of their free (as in beer) commercial client. In actuality, the server is not really a server at all. When a connection is attempted, the client initiates an SSH session to an already existing instance of the SSH daemon using the account "nx", and a supplied DSA key file. Once the client has established a connection, the shell of the nx user account is invoked: nxserver. Nxserver listens to commands from the client, which starts by exchanging some information about the client and server versions, then sends the "LOGIN" command. This causes nxserver to ask for a username and password, which is sent by the client. This is a user who already has an account capable of being authenticated by PAM, in any method that PAM supports. Once the user is authenticated, a list of sessions for that user is requested. If a suspended session is found, the client(nxclient > 1.3.2) will automatically attempt to reconnect to that session, otherwise, a new session is started. NOTE: If SSL Encryption is not enabled, the client will attempt to connect to the port assigned by nxagent. This requires that ports 5000-5200 be opened on your firewall and forwarded into the server. If SSL Encryption is enabled by the client, the nxserver will tell nxnode to tunnel back through the SSH session, allowing for minimal firewall configuration. This will be the most common setup, and the one discussed in the following paragraphs. In the case of a new session, the startsession command is called. This starts a loopback ssh session as the authenticated user. Once that session is established, nxnode is called which takes parameters from the client and passes them to nxagent. This starts the server's proxy system, and allows for an X session to be started, compressed, cached and sent over to the client system, all according to the parameters sent by the client. In the case of a resume, the restoresession command is called. Nxnode starts the loopback ssh, and attempts to reattach to the running session, then proxies the connection over the ssh link. NOTE: The client isn't smart enough to attach to a session that was suspended by a different client. It requires some information from the original session including the exact geometry of the suspended session. Nxnode can also proxy connections for VNC and RDC, calling nxviewer and nxdesktop (respectively). The parameters specified by the client tell nxserver which proxy agent to use. [Installation] FreeNX requires that the GPL'd !M components already be installed. Most distributions are starting to publish their own packages for NX and FreeNX, so the easiest installation method would be to find your distributions package. If not, you will need to download and compile the sources from NX. As prerequisites you will also need expect, openssh, netcat, perl, and a flavor of XFree86 (X.org works too). Download the following: nxproxy, nxcomp, nxcompext, nx-X11, nxagent, nxviewer, and nxdesktop from: http://www.nomachine.com/download/snapshot/nxsources/ into the same directory, then do the following: find -name '*.tar.gz' -exec tar -xzf {} \; # return to the directory where you extracted everything # after each step cd nxcomp && ./configure && make cd nxproxy && ./configure && make cd nx-X11 && make World cd nxcompext && ./configure && make cd nxviewer && xmkmf -a && cp -a /usr/X11R6/lib/libXp.so* \ ../nx-X11/exports/lib && make && make install DESTDIR=../ \ cd nxdesktop && ./configure --prefix=/usr --sharedir=/usr/lib/NX && make \ && make install DESTDIR=../ # do the following as root ( su - ) mkdir -p /usr/lib/NX/lib cp -a nx-X11/lib/X11/libX11.so* \ nx-X11/lib/Xext/libXext.so* \ nx-X11/lib/Xrender/libXrender.so.* \ nxcomp/libXcomp.so.* \ nxcompext/libXcompext.so* \ /usr/lib/NX/lib cp -a usr/X11R6/bin/nxviewer \ usr/X11R6/bin/nxpassword \ usr/bin/nxdesktop \ nx-X11/programs/Xserver/nxagent \ /usr/bin chmod 755 /usr/bin/nxviewer \ /usr/bin/nxpassword \ /usr/bin/nxdesktop \ /usr/bin/nxviewer Also add the following line to /etc/ld.so.conf: /usr/lib/NX/lib and run ldconfig to update. Once the NX backend is in place, install the FreeNX server component. Grab the latest tar.gz for FreeNX, and do the following as root ( su - ): tar -xzvf freenx-0.2.5.tar.gz cd freenx-0.2.5 cp nx* /usr/bin chmod 755 /usr/bin/nxclient \ /usr/bin/nxnode \ /usr/bin/nxserver \ /usr/bin/nxkeygen \ /usr/bin/nxnode-login \ /usr/bin/nxsetup [Server Setup] For most users, nxsetup is the preferred and easiest method of configuring the server. Some packages do the setup for you. If you aren't so lucky, Do the following as root ( su - ): /usr/bin/nxsetup This script will setup the configuration directory, the "nx" user account, its home directory and DSA keys, and user loopback DSA keys. By default and for security reasons, unique DSA keys are generated by nxkeygen. It is also possible to use the key from !M. To setup this key, do the following: /usr/bin/nxsetup --setup-nomachine-key If you choose this method, please read the security section for possible issues. If you want to change some of the default locations for setup, edit /usr/bin/nxserver, and have a look at the configuration variables towards the top. Change them to the values you want, and then run nxsetup. NOTE: Nxsetup will fail if the "nx" user account exists. [Client Setup] The easiest method is to download and install the commercial client from www.nomachine.com. You will find installation packages for various platforms, as well as installation assistance, and mailing lists for client support. For the best security and features, such as resume, you will want to download the latest client snapshot. This can be found in the developer section. After installation you must copy client.id_dsa.key from the server to the client machine. On the server the file resides at: /home/.nx/.ssh/client.id_dsa.key and must be copied to the following location on the client machine: /usr/NX/share/client.id_dsa.key # NOTE: Make sure that your client machine user has rights to that file If you are using a Win32 client, copy the file to: c:\windows\nx client for windows\share\client.id_dsa.key [Server Removal] For complete removal, do the following: # it is a good idea to backup the client.id_dsa.key and # server.id_dsa.pub.key from the "nx" users .ssh directory userdel -r nx rm -rf /etc/nxserver rm -f /usr/bin/nxagent \ /usr/bin/nxviewer \ /usr/bin/nxpassword \ /usr/bin/nxdesktop \ /usr/bin/nxclient \ /usr/bin/nxnode \ /usr/bin/nxserver \ /usr/bin/nxkeygen \ /usr/bin/nxnode-login \ /usr/bin/nxsetup rm -rf /usr/lib/NX [Security] Whenever adding an externally available service, new vectors for malicious activity arise. It is important to be aware of the ramifications of any setting that is changed, and what capabilities your server provides. SSH is a very powerful tool, and FreeNX being heavily dependent upon SSH can permit unwanted activity under specific circumstances. Problem: Certain scenarios may require the nxserver to be setup with the !M key. This problem can also be extended to situations where the key is shared (i.e. More than 1 user). Since the original !M commercial nxserver implementations used SSH's port forwarding capabilities, earlier clients required that port forwarding be enabled in the servers SSH configuration. As FreeNX utilitzes the authorization methods of SSH, it is possible to logon to an SSH server using the account nx and !M's default DSA key. This, in itself, does not give access to the server, but the port forwarding features of SSH allows for an instant proxy. NOTE: This is not specifically a problem with FreeNX, but a problem with guest and anonymous SSH servers in general. Resolution: If you must retain the !M key, it is imperative that users upgrade to the latest client (at the time of this writing nxclient >= 1.4.0-57). The latest clients allow the nxserver to forward the data in a way that does not utilize SSH's port forwarding. Once the client has been upgraded, disable port forwarding in /etc/ssh/sshd_config. To do this, Add the following line to the config file and restart sshd: AllowTCPForwarding no Problem: I want to enable FreeNX access for some users, but disable it for others. Resolution: Find and following line in /usr/bin/nxserver and change the value to "1": ENABLE_USER_DB="0" Next, add the users you want to give access to the run NX remotely like this: /usr/bin/nxserver --adduser {username} Problem: For added security, I run my SSH server on a non-standard port. How do I make FreeNX use this port? Resolution: Find and following line in /usr/bin/nxserver and change the value to the needed port: SSHD_AUTH_PORT="22" Problem: I need to disable NX logons completely. How do I do this, short of pulling my ethernet cable? Resolution: As root, issue the following: /usr/bin/nxserver --stop This renames the nx user's authorized_keys2 file, making it impossible to logon as nx. To reallow nx connections, do this: /usr/bin/nxserver --start [Troubleshooting Tips] When doing brand new installation, always perform the actions as root, in a logon shell ( su - ). Not doing so may result in an error when running setup. If you feel that you may have missed something, try cleaning the configuration, and rerunning nxsetup. Do this: userdel -r nx rm -rf /etc/nxserver /usr/bin/nxsetup If you are using X.org on the server, you most likely will get an Xkb error when logging on with NX. To resolve this error, do this: cd /usr/X11R6/lib/X11/xkb/rules ln -sf xorg-it.lst xfree86-it.lst ln -sf xorg.lst xfree86.lst ln -sf xorg.xml xfree86.xml # this last one may already exist ln -sf xorg xfree86 If you are getting a public key denied error message, it may be related to sshd_config settings or DSA key permissions. You can test the connection with a normal SSH client by doing this on the client machine: mv ~/.ssh/id_dsa ~/.ssh/id_dsa.bak cp /usr/NX/share/client.id_dsa.key ~/.ssh/id_dsa chmod 600 ~/.ssh/id_dsa ssh nx@{SERVER} You might want to enable SSH debugging on the Server, to see the exact errors being returned by SSH. Add this to sshd_config and restart the sshd service: LogLevel DEBUG3 The log file for SSH is typically /var/log/secure. Tail it on the server to watch as you're troubleshooting. tail -f /var/log/secure Remember to remove the sshd entry after you are done troubleshooting, and restart the service. Changelog * Thu Oct 21 2004 Rick Stout - 1 - Changed Line 271 to something a little less invasive was "rm -rf /etc" :) - Fixed a typo in line 82 * Thu Oct 21 2004 Rick Stout - 0 - Original Release