Setting up NX Client access to Linux servers running FreeNX/NX

In order to talk to a Linux box running FreeNX/NX server...

1) Grab a copy of the NX client from NoMachine's download page. For Windows users, look for "NX Client for Windows".

2) Install the client software.

3) Start up "NX Client for Windows".

4) The "Login" field will be your username on the Linux server (i.e. "thomas"). The "Password" field is obviously, your login password on the Linux server. In the "Session" field, enter a descriptive name of the server that you are trying to connect to. (This name does not have to reflect the server's DNS name, IP address and can be any name or nickname.)

5) As you press [Tab] to leave the "Session" field, you will be prompted whether you want to "Create" a new session or "Rename" the existing session. In most cases, you'll want to pick "Create" so that you can setup a new session.

6) You will now be taken to the advanced configuration screen.

a) Server Host: Enter the fully qualified DNS name, or the IP address.
b) Server Port: Most servers run SSH on port 22.
c) Desktop: I usually use "Unix / Gnome"
d) Speed: ISDN or ADSL is a good first choice
e) Display: Choose full-screen or setup a window of any size that you want.

7) Before you click "Save" or "OK", check with your server administrator and find out whether you need to provide the NX client with a custom key. This key is located on the Linux server and is usually at the following location:

/etc/nxserver/client.id_dsa.key

If you need this key, be sure to obtain it, then use the "Server, Key" button on the advanced configuration screen. Just paste the key in to the provided box and you'll be able to talk to the server.

8) Click "Save" then "OK".

9) If everything is configured properly, you can now enter your login password and press the "Login" button to access the remote server.

...

When you are finished with your session on the remote server, you can either "Terminate" (logout) or "Suspend" it if you want to leave things running for later.

Setting up FreeNX/NX on CentOS 5

Quick guide to setting up FreeNX/NX. This the approximate minimums on a fresh CentOS 5.1 box. We're limiting things to using public-key authentication from the outside and we already have a second ssh daemon running (listening on localhost, allowing password authentication).

Note: If you have ATRPMs configured as a repository, make sure that you exclude nx* and freenx*. (Add/edit the exclude= line in the ATRPMs .repo file.)

# yum install nx freenx
# cp /etc/nxserver/node.conf.sample /etc/nxserver/node.conf
# vi /etc/nxserver/node.conf

Change the following lines in the node.conf file:

ENABLE_SSH_AUTHENTICATION="1"
-- remove the '#' at the start of the line

ENABLE_SU_AUTHENTICATION="1"
-- remove the '#' at the start of the line
-- change the zero to a one

ENABLE_FORCE_ENCRYPTION="1"
-- remove the '#' at the start of the line
-- change the zero to a one

Change the server's public/private key pair:

# mv /etc/nxserver/client.id_dsa.key /etc/nxserver/client.id_dsa.key.OLD
# mv /etc/nxserver/server.id_dsa.pub.key /etc/nxserver/server.id_dsa.pub.key.OLD
# ssh-keygen -t dsa -N '' -f /etc/nxserver/client.id_dsa.key
# mv /etc/nxserver/client.id_dsa.key.pub /etc/nxserver/server.id_dsa.pub.key
# cat /etc/nxserver/client.id_dsa.key

You'll need to give the DSA Private Key information to people who should be allowed to use FreeNX/NX to access the server.

You'll also need to put the new public key into the authorized_keys2 file:

# cat /etc/nxserver/server.id_dsa.pub.key >> /var/lib/nxserver/home/.ssh/authorized_keys2

# vi /var/lib/nxserver/home/.ssh/authorized_keys2

Comment out the old key, put the following at the start of the good key line.

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/usr/bin/nxserver"

Restart the FreeNX/NX service:

# service freenx-server restart

You should now be able to connect (assuming that you specify the proper SSH port and paste the private key into the configuration).

Setup sshd to run a second instance

In order to lock down the servers like I prefer to, yet still allow FreeNX/NX to work, I have to setup a second copy of the sshd daemon. The FreeNX/NX client requires that you have sshd running with password access (not just public key), but we prefer to only allow public-key access to our servers.

I did the following on CentOS 5, it should also work for Fedora or Red Hat Enterprise Linux (RHEL). But proceed at your own risk.

1) Create a hard link to the sshd program. This allows us to distinguish it in the process list. It also makes sure that our cloned copy stays up to date as the sshd program is patched.

# ln /usr/sbin/sshd /usr/sbin/sshd_nx

2) Copy /etc/init.d/sshd to a new name

This is the startup / shutdown script for the base sshd daemon. Make a copy of this script:

# cp -p /etc/init.d/sshd /etc/init.d/sshd_nx
# vi /etc/init.d/sshd_nx

Change the following lines:

# processname: sshd_nx
# config: /etc/ssh/sshd_nx_config
# pidfile: /var/run/sshd_nx.pid
prog="sshd_nx"
SSHD=/usr/sbin/sshd_nx
PID_FILE=/var/run/sshd_nx.pid
OPTIONS="-f /etc/ssh/sshd_nx_config -o PidFile=${PID_FILE} ${OPTIONS}"
[ "$RETVAL" = 0 ] && touch /var/lock/subsys/sshd_nx
[ "$RETVAL" = 0 ] && rm -f /var/lock/subsys/sshd_nx
if [ -f /var/lock/subsys/sshd_nx ] ; then

Note: The OPTIONS= line is probably new and will have to be added right after the PID_FILE= line in the file. There are also multiple lines that reference /var/lock/subsys/sshd, you will need to change all of them.

3) Copy the old sshd configuration file.

# cp -p /etc/ssh/sshd_config /etc/ssh/sshd_nx_config

4) Edit the new sshd configuration file and make sure that it uses a different port number.

Port 28822

5) Clone the PAM configuration file.

# cp -p /etc/pam.d/sshd /etc/pam.d/sshd_nx

6) Set the new service to startup automatically.

# chkconfig --add sshd_nx

...

Test it out

# service sshd_nx start
# ssh -p 28222 username@localhost

Check for errors in the log file:

# tail -n 25 /var/log/secure

...

At this point, I would go back and change the secondary configuration to only listen on the localhost ports:

ListenAddress 127.0.0.1
ListenAddress ::1

...

References:

How to Add a New "sshd_adm" Service on Red Hat Advanced Server 2.1

How to install NX server and client under Ubuntu/Kubuntu Linux (revised)

...

Follow-on notes:

This setup is specifically for cases where you do not want to allow password access to the server from outside. The way that the NXClient authenticates is basically:

1) NXClient uses a SSH public key pair to authenticate with the server

2) It then logs into the server using the supplied username/password via SSH.

So by setting things up this way, we keep public-key authentication as the only way to login to the server - but the NX server daemon is able to cross-connect to a localhost-only SSH daemon.

FreeNX/NX Security

After mucking around with NX/FreeNX, I have a general understanding of how it works, how to lock down your server and what some of the security ramifications are.

First line of defense - NX user key pair

NX/FreeNX clients connect to your Linux server using a special user account (always named "nx") via your SSH service. This user can login using a SSH public/private key pair, which means better security and control over who can attempt to connect to the NX server daemon. However, the default NX server ships with a pre-defined public key pair, which renders this line of defense useless.

(That statement is based on the freenx.x86_64 package (v0.7) currently available as an RPM.)

The server's key files are located under the following names on CentOS/RedHat:

Public Key: /etc/nxserver/server.id_dsa.pub.key
Private Key: /etc/nxserver/client.id_dsa.key

The private key is what needs to be handed out to your users. They will then place this private key into their NX client configurations in order to login and talk to the NX server.

The official NX server has a "--keygen" command that can be used to create a new key pair for increased security. But FreeNX 0.7 does not currently feature that ability. Instead, we must use the ssh-keygen command (part of OpenSSH) to create new key files. Make sure that you make backup copies of the above key files before using the following commands.

Note: DSA keys are always 1024 bits.

# cd /etc/nxserver/
# ssh-keygen -t dsa -f /etc/nxserver/new-dsa-key -N ''
# mv client.id_dsa.key client.id_dsa.key.OLD
# mv server.id_dsa.pub.key server.id_dsa.pub.key.OLD
# mv new-dsa-key client.id_dsa.key
# mv new-dsa-key.pub server.id_dsa.pub.key
# service freenx-server restart
# cat server.id_dsa.pub.key
# /var/lib/nxserver/home/.ssh
# vi authorized_keys2

You will then need to change the old key line to match the new public key. At this point, until you update any clients with the new private key file (client.id_dsa.key), they will be unable to connect to the server.

# cat /etc/nxserver/client.id_dsa.key

Note: FreeNX seemingly stores the client.id_dsa.key in two places (/etc/nxserver and under /var/lib/nxserver/home/.ssh).

Second line of defense - sshd_config

The default FreeNX install on CentOS/RedHat requires that your users can authenticate via passwords to SSH. Obviously, not ideal, but we'll cover that in a few minutes. For the moment, make sure that your /etc/ssh/sshd_config file contains the following settings:

PermitRootLogin no
PasswordAuthentication yes

You should now be able to login using the NX client software to your server. The username should be an account in /etc/passwd for which you know the password.

Locking down SSH #1 - use a non-standard port

For servers that face the public internet, using the default SSH port of 22 is an open invitation for people to try and crack your SSH server (dictionary attacks, brute-force, overflows). While SSH using only public keys is very secure, all of the attack attempts will generate entries in your logs and are basically a nuisance.

Probably one of the easiest fixes to avoid most brute-force attacks is to run SSH on a non-standard port. This requires making two changes (and you'll need to let anyone else who talks to your servers via SSH know about the port change):

1) Change the port number in /etc/ssh/sshd_config:

#Port 22
Port 9822

2) Change /etc/nxserver/node.conf

#SSHD_PORT=22
SSHD_PORT=9822

3) Restart the two services

# service freenx-server restart
# service sshd restart

When you connect with the NX client, you will have to remember to specify the non-standard port number in the connection details.

Re-locking SSH, closing the password authentication hole

Key links:

[FreeNX-kNX] FreeNX, SSH, and su
Re: [SLE] Resolved - Setting up NXfree to use ssh keys
How to remote desktop using SSH and FreeNX

Now that we've gotten NX working using password authentication, it's time to close that hole back up. In order to do this, you have two choices:

...

(Someday I'll finish this post. Probably have to run 2 copies of sshd, with different security settings.)

Methods ofr remote GUI control of Linux servers

There are currently (3) basic methods for getting a remote control GUI on a Linux server (like we do with Remote Desktop for Windows servers):

1) X-Windows over TCP/IP

All GUI operations on Unix/Linux are handled by the X-Windows sub-system. Window interfaces like KDE, Gnome, and others are merely layered on top of the X sub-system. One of the useful things about X is that any window can be forwarded over TCP/IP to any other X server. So you could run an application on the linux server, but display the output window on your PC (as long as you run a local X server program).

The downside of all this is that accessing remote servers requires the use of SSH port forwarding, and a bit of arcane magic. It's nowhere near as clean of a solution as RDP (Terminal Services). But it can be ultra-secure (by using SSH keys) and it works fairly well across the WAN.

2) VNC

VNC is a screen-scraper solution for GUI desktops, very similar to the old pcAnywhere and e/pop solutions that we used to use.

The downsides of VNC are:
- security is non-existent in the base spec
- different VNC server use different encryptions
- authentication tends to be done via plain text passwords
- rather slow across the WAN

3) NX/FreeNX

A company called NoMachines came out with a different solution called "NX". NX is a protocol that is very similar to RDP and the client works rather similar to Remote Desktop. You used to have to pay for the product, but over the years, they've opened up the source code. So now there are (3) different server implementations (NX, FreeNX, and another) and you can download the NX client from NoMachines for free.

The big advantage here is that security is better and performance is better over slow WAN links.