24 June 2013

Dual factor SSH: Google Authenticator, SElinux, and CentOS

 

Intro

Dual factor authentication often requires the purchase of RSA tokens or some similar physical piece of hardware. Even the much touted Yubikey cost $25 a unit. Google Authenticator is quickly becoming one of the new standards for implementing a dual factor solution using a smart phone instead of a purchased token. 

The Google Authenticator PAM allows time-based dual factor authentication on a Linux machine. The installation is documented on the Google Authenticator wiki in a couple of lines, but little is said about implementation with SE Linux enabled. Most other blogs simply state, "Turn off SE Linux", which seems less than ideal. 

Here is an end to end set up for Google Authenticator on Cent OS 6.4.  


Installation - Method 1 (via RPM)

Easy, but not recommended.

Enable the EPEL repository, if not already enabled. 

For example: 

# wget http://mirror.symnds.com/distributions/fedora-epel/6/i386/epel-release-6-8.noarch.rpm
# yum localinstall epel-release-6-8.noarch.rpm

Then install via yum. 

# yum install google-authenticator

The downside of this is the RPM is most likely not the most up to date.

Installation - Method 2 (via make) 

Not so difficult and recommended.

Make sure you have pam-devel (yum install pam-devel) installed. Then clone latest from Google. 

# git clone https://code.google.com/p/google-authenticator/

Change into the build directory. 

# cd google-authenticator/libpam/ 

Then do the build. 

# make && make install
 

Basic Server Set up

Two places have to be modified, the sshd configuration file and the PAM configuration file. 

In /etc/ssh/sshd_config ensure the setting match below


PasswordAuthentication yes
ChallengeResponseAuthentication yes
#ChallengeResponseAuthentication no

UsePAM yes


In the PAM file /etc/pam.d/sshd, a new line will need to be added at the top: 

auth   required        pam_google_authenticator.so

Restart the sshd daemon: 

# service sshd restart

That is it for the server. 

If, however, SELinux is enabled, additional configuration is needed (see below). Otherwise, an error like this will appear in /var/log/secure: 


Failed to update secret file "/home/${USER}/.google_authenticator"
error: PAM: Cannot make/remove an entry for the specified session


Basic User Set Up

First, install the Google Authenticator on your mobile phone.

Next, on the Linux system run the Google Authenticator command: 

# google-authenticator

Read and answer the yes/no questions. After setup, the user will have a .google_authenticator file in the home directory. 

The command will also create a URL and/or a QR code. With Google Authenticator on your mobile phone, capture the QR. It will create a new account automatically.

This has to be done for each user.


Advanced Setup for SELinux

Google Authenticator and its incompatibility with SELinux is known. But there is little agreement on how to fix it. Some recommendations include compiling and rolling new SE policies. Others recommend disabling SELinux. But there is a straight forward workaround. 

First, in the PAM file /etc/pam.d/sshd, modify the pam_google_authenticator line: 

auth   required        pam_google_authenticator.so nullok secret=/home/${USER}/.ssh/.google_authenticator

This does several things. First "nullock" tells PAM to accept null if the user does not have the Google Authenticator configured. In other words, users who don't have dual-factor configured can still log in. Next, the "secret= ..." gives PAM access to the needed key file, even with SELinux installed, just as it does for key-based SSH sessions. 

Second, move the
.google_authenticator to the .ssh folder for the user -- it may need to be created. It is best to do this as the user.

# mkdir /home/${USER}/.ssh 
# mv /home/${USER}/.google_authenticator /home/${USER}/.ssh/.google_authenticator


Restart the sshd daemon: 

# service sshd restart

That is it for the SELinux. 


Expected Behavior

  • Users with dual factor configured will need a verification code and a password. 
  • Users with no dual factor configured will only need a password. 
  • This configuration will not work with key-based ssh configurations. They will bypass the dual factor process.


1 comment:

Anonymous said...

I would really appreciate it if you would update this excellent article to be compatible with CentOS 7. Thanks!