Using two-factor authentication on Linux with NoMachine
NoMachine supports two-factor authentication by integrating with a number of authenticator tools. By combining NoMachine login with a third party authenticator, you can create a 2FA set-up and further protect remote access to Linux systems and servers.
A brief introduction about authentication methods
Two-factor authentication is an authentication process made of two methods belonging to two different groups, for example a password + a token. Having two different passwords, instead, doesn't constitute a two-factor authentication. Authentication methods are usually grouped as:
1° group: 'something the user knows', e.g. a password.
2° group 'something the user has', e.g. a token.
3° group 'something the user is', e.g. a biometric data like user's fingerprint.
NoMachine supports one method for the first group ('something the user knows' ) :
- password autentication (with both NX and SSH protocols)
and a number of methods for the second group ('something the user has' ) e.g a token. The following group 2 methods of authentication are currently supported:
i) Private key authentication
ii) Kerberos ticket authentication (with SSH protocol and system login)
iii) Smart card authentication (with SSH protocol and system login)
Choosing one of these three (i,ii,iii) methods excludes the other two.
NoMachine and 2FA
In NoMachine, a 2FA system can be achieved by combining password authentication (factor 1) with a supported third-party authentication set-up (factor 2). NoMachine supports a number of tools such as DUO, Okta, Google Authenticator and RSA. These tools are responsible for generating the code or the ticket to be sent to the user via SMS, e-mail or mobile push notification. For example, you could use password authentication for the first factor and add the second factor by configuring PAM to request a Google authenticator code.
This article proposes different tools that you can integrate with NoMachine's own first factor. The examples tested in our labs are below for various Linux-based systems.
1. How to activate two-factor authentication with NoMachine on client side
NoMachine is ready for using two-factor authentication and doesn't require further configurations to be set. User just needs to select the proper protocol and authentication method from the NoMachine User Interface (GUI), for example SSH protocol + password.
2. How to activate two-factor authentication when connecting by browser
NoMachine is ready for using two-factor authentication and doesn't require further configurations to be set. Users just need to connect to the NoMachine server from a browser and provide their credentials when requested.
|
|||
|
|||
|
Providing information about how to set-up a third party software is beyond the scope of this article. Users should refer to the official documentation of the software they have choosen. Examples below, tested in our labs, are provided 'as is'. Instructions to set up two-factor authentication on Linux usually require to configure PAM and SSHD (the SSH server). Since NoMachine uses its own PAM configuration (/etc/pam.d/nx), it's necessary to modify such configuration to enable two-factor authentication. Restarting the NoMachine server is not required, changes will be effective when a new connection is created or a virtual desktop is reconnected. Additionally, when users connect to NoMachine via the SSH protocol, two-factor authentication needs to be enabled also in the /etc/pam.d/sshd configuration file. Restarting SSHD is required to make changes effective. Before applying our examples, please consider that specific PAM/SSHD configurations may be requested by your Companies' policies. Additionally, depending on the Linux distributions, required settings may be different. We therefore recommend to refer also to the official documentation of your Linux distribution. |
|||
SOME EXAMPLES
to set-up a third party authenticator on Linux
You need to have either root or sudo privileges on the machine where you want to configure the two-factor authenticator.
3.1. Example 1: use OATH Toolkit
Instructions below have been tested on Ubuntu 12.04 and have to be executed from a terminal.
1. Ensure that time is set accurate on our server.
Install the Network Time Protocol daemon (ntpd) and run:
ntpd -q -g
2. Install the OATH Toolkit:
apt-get install -y libpam-dev
wget http://mirror.csclub.uwaterloo.ca/nongnu/oath-toolkit/oath-toolkit-1.10.0.tar.gz
tar -xzf oath-toolkit-1.10.0.tar.gz
cd oath-toolkit-1.10.0
./configure && make && make install
ln -s /usr/local/lib/security/pam_oath.so /lib/security/
ln -s /usr/local/lib/liboath.* /lib/
3. Set-up SSH keys.
It's necessary to generate a random key and save it into a file readable only by root.
The following instructions assume you have 'sudo' installed and $SUDO_USER is your normal user name.
KEY=$(head -c 1024 /dev/urandom | openssl sha1)
echo "Your secret key is: $KEY"
echo "HOTP/T30/6 $SUDO_USER - $KEY" >> /etc/users.oath
chmod go-rw /etc/users.oath
Settings above are for a 6 digit time based OTP with a window of 30 seconds.
Copy this key in a safe place and/or immediately setup your token (eg. your phone) with this key.
4. Set-up SSHD.
Run the following command:
sed -i.bak -E -e 's/(ChallengeResponseAuthentication) no/ yes/' /etc/ssh/sshd_config
5. Configure PAM.
open the /etc/pam.d/sshd file with text editor and find the following line:
@include common-auth
than change this line to have:
auth required pam_unix.so nullok_secure
and add the following to the end of file:
# OATH OTP
auth required pam_oath.so usersfile=/etc/users.oath
NOTE that:
i) The '@include common-auth' is necessary to provide users with the client GUI deserved to OTP password. If it's missing, users will be provided with the normal username-password-save password GUI.
ii) Order of directive is relevant because PAM configuration is in sequence. The '@include common-auth' must be placed before the 'auth required...' instruction.
6. Restart SSHD:
service ssh restart
7. Enable two-factor authentication for the NX protocol.
Open the /etc/pam.d/nx file with a text editor and add the following line at the end of the auth section:
auth required pam_oath.so usersfile=/etc/users.oath
3.2. Example 2: use Google Authenticator
All instructions have to be executed from a terminal.
1. Install the necessary software.
To install Google Authenticator on Debian/Ubuntu:
sudo apt-get install libpam-google-authenticator
To install Google Authenticator on RHEL/CentOS:
sudo yum install google-authenticator
2. Configure Google Authenticator and synhronize it with your mobile phone
To start configuring the authenticator run in your command prompt:
google-authenticator
You’ll then be prompted with several questions that will allow you to restrict use of the same temporary security token, increase the time window that tokens can be used for, and limit number of access attempts to hinder brute-force cracking attempts. If you are in doubt about what to choose, its suggested to answer 'yes' on all questions.
You will also have a secret key, a verification code and emergency scratch codes. Write them in a safe place, these codes will be used later.
3. Install Google Authenticator on your mobile phone.
Install Google Authenticator from the Google Play Store.
When you start this application, choose the 'Enter provided key' option and write your secret key there.
4. Enable two-factor authentication for SSH protocol
4.1. Edit the /etc/pam.d/sshd file
On Ubuntu (tested on Ubuntu 14.04)
Open the /etc/pam.d/sshd file with a text editor and add the following line at the end of the auth section:
@include common-auth
auth required pam_google_authenticator.so
Note that:
i) The '@include common-auth' is necessary to provide users with the client GUI deserved to OTP password. If it's missing, users will be
provided with the normal username-password-save password GUI.
ii) Order of directive is relevant because PAM configuration is in sequence. The '@include common-auth' must be placed before the 'auth required...' instruction.
On RHEL 7/CentOS 7
Open the /etc/pam.d/sshd file with a text editor and add the following line at the bottom of the file:
auth required pam_google_authenticator.so
On RHEL 6/CentOS 6
Open the /etc/pam.d/sshd file with a text editor and delete (or comment out) line:
auth include password-auth
and add the following lines below (order is relevant!):
auth required pam_env.so
auth required pam_unix.so nullok try_first_pass
auth required pam_google_authenticator.so
auth requisite pam_succeed_if.so uid >= 500 quiet
4.2. Then open the /etc/ssh/sshd_config file and add the following line:
ChallengeResponseAuthentication yes
PasswordAuthentication no
4.3. Finally restart your SSHD.
on Ubuntu:
sudo service ssh restart
on Fedora:
sudo systemctl restart sshd
on RHEL/CentOS:
sudo service sshd restart
5. Enable two-factor authentication for NX protocol.
On Ubuntu and CentOS 7
Open the /etc/pam.d/nx file with a text editor and add the following line at the end of the auth section:
auth required pam_google_authenticator.so
On CentOS 6
Open the /etc/pam.d/nx file with a text editor and delete and comment this line:
auth include su
Then add the following lines below at the end of the auth section:
auth required pam_env.so
auth sufficient pam_fprintd.so
auth required pam_unix.so nullok try_first_pass
auth required pam_google_authenticator.so
auth requisite pam_succeed_if.so uid >= 500 quiet
3.3. Example 3: use RSA Authentication Manager
1. Download RSA Authentication Agents for PAM:
https://www.rsa.com/en-us/products-services/identity-access-management/securid/authentication-agents/authentication-agents-for-pam
Install RSA Authentication Manager. Version required is 6.1.2 or higher
2. Copy the sdconf.rec file from the RSA Authentication Manager to an accessible directory, such as /var/ace/.
3. Specify the Agent Host IP Address
3.1. Use a text editor to create the sdopts.rec file in the path where the sdconf.rec file is saved.
3.2. Type:
CLIENT_IP=x.x.x.x
where x.x.x.x is the IP address of the agent host
and save the file
4. Configure SSH
4.1. Edit the /etc/ssh/sshd_config file.
4.2. Set the UsePAM parameter to: yes.
4.3. Set the PasswordAuthentication parameter to: no.
This disables the OpenSSH password prompt so that the PAM agent is used instead. As a result, the user will be only prompted for the RSA SecurID passcode.
4.4. Set the UsePrivilegeSeparation parameter to: no.
4.5. Set the ChallengeResponseAuthentication parameter to: yes.
5. Install the PAM agent
5.1. Move to the PAM agent installer directory.
5.2. Untar the downloaded file by executing:
tar zxvf <filename.tar.gz>
For example:
tar zxvf PAM-Agent_v7.1.0.1.25_RHEL.tar.gz
5.3. Run the install script by executing:
./<filename>/install_pam.sh
For example:
PAM-Agent_v7.1.0.1.25_RHEL/install_pam.sh
5.4. Enter the prompts until you are prompted for the sdconf.rec directory:
If the path is correct, press ENTER.
Otherwise enter the correct path.
5.5. For each of the subsequent installation prompts, press ENTER to accept the default value or enter the appropriate value.
6. Add SecurID module to PAM config of sshd
6.1. Change to the /etc/pam.d directory.
6.2. Open the sshd file.
6.3. Comment lines beginning with "auth"
6.4. Add the line:
auth required pam_securid.so
7. Troubleshooting
To enable debug output for the PAM agent, edit the /etc/pam.d/sshd configuration file by adding a debug argument:
auth required pam_securid.so debug
3.4. Example 4: configuring two-factor authentication to work with just one password prompt
Let's assume that NoMachine server is installed on CentOS 7 and that a local system account exists for the user who will connect by NoMachine.
This example will use Google Authenticator.
1) Install:
- NoMachine server, for example the Workstation.
- pam-devel, make, gcc-c++, git
2) Clone the Google Authenticator repository:
cd /tmp && git clone https://github.com/google/google-authenticator.git
3) Build Google Authenticator
./bootstrap.sh
./configure
make
make install
NOTE: By default, Google Authenticator library installs to /usr/local/lib. You may wish to copy /usr/local/lib/security/pam_google_authenticator.so -> /usr/lib64/security/pam_google_authenticator.so /usr/local/lib/security/pam_google_authenticator.la -> /usr/lib64/security/pam_google_authenticator.la
4) Setup the user's Google Authenticator
- sudo su to the user
- run:
/usr/local/bin/google-authenticator
and follow the prompts
- Edit the /etc/pam.d/nx file as follows (commented lines are the original configuration)
#auth include su
#account include su
#password include su
#session optional pam_loginuid.so
#session include su
auth requisite /usr/local/lib/security/pam_google_authenticator.so forward_pass
auth required pam_sss.so use_first_pass
account required pam_nologin.so
account include password-auth
session include password-auth
You should now be able to log in to NoMachine with username + password and the Google Authenticator token appended. If the user's password is "Secret1" and token is "123456" the nomachine password would now be "Secret1123456".
3.5. Example 5: configuring NoMachine to use Duo
Prerequisite:
Duo authentication is already configured to work correctly with system SSH, i.e. the user should be able to login by plain SSH (without NoMachine being involved) and Duo authentication.
In case, please consult the official Duo documentation at: https://duo.com/docs/ and if it's needed to add also the YubiKey: https://duo.com/docs/yubikey
Once done, try to connect by NoMachine and SSH protocol: users should be able to authenticate with Duo out-of-the-box.
For connections by NX protocol, instead, it's necessary to edit the NoMachine's PAM configuration and specify the correct Duo auth library. Add it to the /etc/pam.d/nx file.
For example:
auth required /lib64/security/pam_duo.so
Refer to the system SSH configuration file, /etc/pam.d/ssh to find the exact line to add.
IMPORTANT: NoMachine is able to work with Duo 2FA only when the 'password' authentication method is selected in the connection settings in the client UI.
3.6. Example 6: How to use Okta MFA with NoMachine on Linux
Please refer to: https://kb.nomachine.com/AR06S01134
