It is sometimes necessary, in specific deployment scenarios, to 'lock down' a server and restrict 'general' SSH logins to only a specific subset of the users defined on the whole system. For instance, imagine a public NoMachine Server host providing access to a distributed client environment over the whole Internet.

In NoMachine version 6 or later the natural way to forbid users from connecting by any other means than NoMachine, is to stop system services like SSH, FTP etc ... and use the built-in NX protocol.  Users will be therefore limited to connect to the remote host only by NX protocol. The NX protocol, which is the native protocol of NoMachine available since v. 4, is implemented using OpenSSL TLS/SSL and uses cryptography to protect data: https://www.nomachine.com/AR10K00705 . NoMachine connections by NX protocol use port 4000 by default, but this port can be changed.

Another option is to allow SSH connections on port 22: in this case it will be necessary to keep SSHD up and running. Limitations to users' access can be reached via SSHD configuration (e.g. specify in the AllowUsers key which user can access the system by SSH clients). Restarting the SSHD server is requested to make the change effective.

It's possible to configure the system to restrict the SSH login:

(i) How to restrict SSH login to a single command, 'nxserver --login' and require key-based authentication

Step 1

Configure SSHD to allow only key-based authentication.

1.1. Create a restricted directory on the server host where to store the authorized_keys file for the user.
     
     Let's say that this directory, accessible only by administrators, is:

     /restrictedkeys

      If SELinux is enabled, set the appropriate context:

      restorecon -R -v /restrictedkeys/
           

   
1.2. Instruct SSHD about where to look for authorized keys and disable password based authentication.

     Edit the SSHD configuration file, usually /etc/ssh/sshd_config and set:

     AuthorizedKeysFile    /restrictedkeys/%u/authorized_keys
     PasswordAuthentication no

     Directory /restrictedkeys should be owned by root, with permissions 1555 (read-execute for everyone).

     Note: %u is replaced by the username being authenticated.

1.3. Restart SSHD to make this change effective.

Step 2

Create the 'NoMachine restricted shell', for example in:

  /opt/restrictedshell

It could contain:

#!/bin/bash
echo "Welcome";
read command1
echo "Linux"
read command2
exec /etc/NX/nxserver --login

Ownership: root (chown root /opt/restrictedshell)
Permissions:755 (chmod 755 /opt/restrictedshell)

Step 3.

Restrict user's SSH login

3.1. Generate a private-public key pair.
 
3.2. Create the directory where keys will be stored.

      Create a directory for user as:

      /restrictedkeys/%u

      Where %u must be replaced with the username.
     
      Ownership: this user (chown user:usergroup /restrictedkeys/%u)
      Permissions: 500 (chmod 500 /restrictedkeys/%u)

3.3. Create the authorized_keys file for the user in the /restrictedkeys/%u directory.
 

3.4. Add the public key to the user's authorized key file

      For example, if the user is nxtest01 and the public key is my_key.pub:      
    
      cat my_key.pub >> /restrictedkeys/nxtest01/authorized_keys   

      Add prefix command="/opt/restrictedshell" to the key in authorized_keys file.

      Finally, it should look similar to:

command="/opt/restrictedshell" ssh-dss AAAAB3NzaC1kc.......W/5O+8=

3.5. Set correct permissions and ownership

    Be sure that the authorized_keys file has correct ownership and permissions.

    Ownership: the user (chown username:usergroup /restrictedkeys/useriname/authorized_keys)
    Permisisions: read only for the owner (chmod 0400 /restrictedkeys/useriname/authorized_keys)

Step 4

Distribute the SSH private key to each user.

For avoiding to transport the private key, you may consider to ask users for generating the keys by themselves and share their public key only, which could be transported without risk.

Step 5

How to authenticate by SSH and private key via NoMachine

 On the user's computer:

- Launch the NoMachine User Interface from Programs menu or Applications and right click on a connection. Choose 'Edit connection'  to access connection settings.

- Be sure that SSH is the selected protocol in the drop-down menu.

- Click on the Advanced button.

- Choose 'Private key'  authentication and click  on the 'Settings' button.

- Click  the '...' button navigate directories and provide path to your private SSH key (e.g. my_key).

- Click on 'OK' button and connect.

The client will prompt you for username and passphrase. If your SSH key doesn't have a passhprase, leave this field empty.

(ii) How to restrict SSH login to a single command, 'nxserver --login' and require password authentication

We provide an sample script to be used for restricting SSH login and use password based authentication. We strongly advise to evaluate this script in accordance with your Company's security policies.

The script, we named it nxrestrictshell, has to be set as user's shell.
 

Step 1

Configure the SSHD server on the Cloud Server host to accept password authentication: 

PasswordAuthentication yes

and restart it.
 

Step 2

The nxrestrictshell script:

#!/bin/bash
comm=$(/bin/cat /proc/$PPID/comm)
if test "$comm" = "sshd";
 then
  echo "Welcome";
  read command1
  echo "Linux"
  read command2
  exec /etc/NX/nxserver --login
fi
exec /bin/bash --login $*

Store the nxrestrictshell script on the Cloud Server host in a safe place not accessible to unprivileged users, for example in /usr/bin.

Set permissions and ownership to the script:

chmod 755 nxrestrictshell
chwon root:root nxrestrictshell

Step 3

Set the nxrestrictshell shell as user's shell.

For example, if the user is 'adam':

sudo chsh -s /usr/bin/nxrestrictshell adam

To verify:

grep adam /etc/passwd
adam:x:1001:1003:adam2:/home/adam:/usr/bin/nxrestrictshell

Appendix for earlier versions

For earlier versions, NoMachine v. 5 and 4 and NX 3.5.0, the following alternatives are possible:

1) The first option to set up two distinct SSH daemons on the NoMachine server host.

2) The second is to modify your SSH daemon configuration and use the capabilities provided by the "AllowUsers" directive.
 

Please see below for a detailed explanation.

First option: set up two distinct SSH daemons

The first SSH daemon will be listening on the public interface: on this daemon administrators can restrict the login to the 'nx' user: no further user needs to be able to connect. Obviously, depending on the specific setup, users with privileged accounts can also be added to the list of allowed logins.

The second SSH daemon will, instead, be listening on the loopback interface. This daemon will be configured to allow a generic user to login.

Administrators will use, for ease of mantainance, two separate configuration files for each daemon and will take care of inserting the appropriate startup/shutdown script at the desired runlevels to perform the activation and deactivation tasks of the corresponding services.
 

Second option: use the "AllowUsers" directive

Insert the following into your sshd configuration file (usually /etc/ssh/sshd_config).

    AllowUsers nx@*.*.*.* *@::ffff:127.0.0.1 *@127.0.0.1

Then stop and start your SSH daemon for the changes to take effect.

The above configuration requires that users connect by SSH protocol and NoMachine login (this can be selected in the connection settings panel of the client GUI). In this way every user's connection by SSH will be blocked, except if the connection is made through NoMachine.

The SSH + NoMachine login method, still supported in v. 4 and 5, is the only available method for v. 3.5.0.