The way NX works is by creating a 'nx' user on the server machine whose shell, /usr/NX/bin/nxserver, is executed any time a remote NX user connects by SSH using nxclient. To access the server, the client uses a public RSA key. Using this public key forces the SSH server to execute the nxserver shell and prevents any possibility for the special user 'nx' to login on the machine outside NX. As the 'nx' user is required to properly function, the username for 'nx' cannot be changed.
To login, the 'nx' user must go through the usual host authentication and SSL key negotiation mechanisms offered by the Transport Level Security built in SSH. This means that all the traffic between the client and the server is effectively encrypted just as the login would have happened if the 'nx' user had gained access to the server by means of an interactive session. By comparison, this use of SSH is in practice the same that HTTPS servers do with the Secure Socket Layer specification to provide secure access to Web content.
Once the user is logged in to SSH, that is they have reached the stage it has entered the nxserver shell, SSH must authenticate to the NX server using any of the available methods. No operation is allowed by the server until the user has authenticated. NX Server can offer arbitrary means for authenticating a user. At the present moment the following methods are supported:
- A separate NX server password database.
- The currently configured system by which SSH checks the user's password, most likely PAM.
In the first case NX tries to match the user's password in its own database. In order to connect, users must be added to the system by a 'nxserver --useradd' command. This offers a separation between system users and NX users, as only users that have been added to the NX system will be able to connect by NX.
The second method offers seamless integration with the PAM system configured on the machine. To verify the password, NX will submit the user's credentials to the SSH subsystem. If SSH guarantees the access, then NX will allow the user to enter the session.
Besides the basic configuration outlined here, NX offers a number of methods for ensuring that the system administrator maintains full control on the set of users that are allowed to connect. This happens by manipulating two distinct databases: the NX user database and the NX password database. Depending on how the system is configured, users that are authenticated by PAM passwords might be required to exist in the NX users database, so that it is possible to guarantee NX access to only a restricted set of system accounts.
To offer a comparison that will probably help the reader to understand how NX works, every action performed on the host system by NX is executed by impersonating the 'nx' user. This is similar to the way a HTTP server like Apache executes programs and parses its input and output by impersonating the user 'http', or to the way the Caching Proxy SQUID, runs under the privileges of the user 'squid'. As this holds true for the 'http' and the 'squid' users, the 'nx' is an unprivileged account and so, even by exploiting a bug that could permit to an attacker to execute arbitrary commands as the user 'nx', the result would be that all users that have not been configured by the system administrator to run NX sessions would be unaffected. As with Apache or SQUID, there is no way for the 'nx' user to gain 'root' privileges (a common way to acquire the control of the critical functions of the operating system) other than by exploiting some other bug that is present in the OS or in a existing program that is allowed to run with 'root' privileges.
Because the NX system has to perform a wide range of operations requiring the privileges of the logged in user, NX acquires these privileges by logging in to the 'nodes' of the NX network where these operations have to be performed by executing the /usr/NX/bin/nxnode shell. The way nxserver logs in to the node is the same method used by clients to get to the server. It uses a RSA key which, similarly to the nxserver key, is restricted to executing the /usr/NX/bin/nxnode command as the impersonated user. It is part of the nxnode's task to execute the commands requested by the server, monitor the running sessions, provide services like logging and error reporting.
NX nodes are obviously designed to be hosts residing anywhere on the Internet, not necessarily the same machine where the NX server is running. The way NX server gains access to the node, in fact, is by leveraging the SSH functionality, as opposed to executing the nxnode commands directly in a local shell. This mechanism provides a layer of separation between the NX server and the NX node, and allows for creating efficient load balancing and fault tolerance in the NX network.
As we have seen in this article, NX relies heavily on both the SSH functionalities and the existing OpenSource SSH software, to make it possible to run contemporary Unix and Windows desktops and arbitrary network applications, across the Internet, in a secured and controlled fashion. NX leverages the same logging and auditing facilities of SSH, as well the secure access to critical authentication records that PAM and SSH provide together. Considered the wide range of features that NX had to provide, designing a system that was expandable and layered on top of established and well-developed standards was the primary concern of the NX architects. We believe that, no matter how good a new stand-alone service written from scratch could have been designed and implemented, creating NX on top of the widely known SSH and HTTPS standards, allows users to build an infrastructure that can be grown and trusted.
Please also see the following related articles about NX and authentication:
http://www.nomachine.com/ar/view.php?ar_id=AR01C00126
http://www.nomachine.com/ar/view.php?ar_id=AR05D00391
