This article will describe how to setup two-factor authentication for a Debian based Linux machine.  This solution will work for console and remote (ssh) logins.  When changing a Linux host to using two-factor authentication, there is actually a couple of options.  I’ll briefly explain the two options and why one was chosen over the other in this particular example.  Before getting to that part, a brief mention of the type of two-factor authentication server that is being used.

RSA Authentication Manager provides an authentication mechanism consisting of a “token” – either hardware (e.g. a Keyfob) or software (application that provides same functionally as a keyfob).  A hardware or software token is assigned to an individual, which generates an authentication code at fixed intervals (usually 60 seconds) using a built-in clock and the tokens factory-encoded random key (known as the “seed”). The seed is different for each token, and is loaded into the corresponding RSA SecurID server (RSA Authentication Manager, formerly ACE/Server) as the tokens are purchased.

In this example, I are using RSA Authentication Manager 6.1, which is running on a purpose built appliance that uses Windows 2003 Server with the RSA server software installed.  This particular solution includes Funk Software’s Steel Belted Radius, which provides a radius authentication mechanism into RSA.  At the time of this writing, this particular appliance and software version is approaching end of life and has since been replaced with Authentication Manager 7.1.  In the appliance version of 7.1 (known as Authentication Manger 3.0), the operating system has moved to Linux with Authentication Manager 7.1 loaded on top of it.  Version 7.1/3.0 also includes a radius server that can be used for radius clients needing to utilize two-factor authentication.

Now, onto the client portion of software used to interface with the RSA server.  As previously mentioned, there are two options, with the first being to use the RSA provided authentication agent for Unix/Linux.  The agent is actually a module that hooks into PAM, which is the central authentication standard used in most modern Unix/Linux systems today.  This option provides the maximimum functionality and interfaces directly with the RSA protocol (which means the RADIUS server is not required).

The second option is to load a RADIUS module into PAM (pam_radius_auth), which would then communicate to the RSA server via it’s built in RADIUS server.  Why would you want to use this option over the first option presented?  The RSA provided client is only supported on  a couple of Linux platforms, namely Red Hat and SuSE, which are both RPM based.  So if you are using any other Linux distribution (Debian based, etc.), there is not an RSA provided option with this client software.

Most Linux software repositories will contain a PAM radius module, which prevents having to download source code and compiling programs.  I’m specifically working on a Debian based system, which includes the module libpam_radius_auth in it’s repository.  The following contains instructions for configuring the system:

First, install the module from the distributions repository:

root@localhost:~# apt-get install libpam-radius-auth
Running /usr/bin/apt-get install libpam-radius-auth
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  radius-server
The following NEW packages will be installed:
  libpam-radius-auth
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 24.7kB of archives.
After this operation, 127kB of additional disk space will be used.
Get:1 http://ftp.us.debian.org lenny/main libpam-radius-auth 1.3.16-4.4 [24.7kB]
Fetched 24.7kB in 0s (58.4kB/s)
Selecting previously deselected package libpam-radius-auth.
(Reading database ... 36010 files and directories currently installed.)
Unpacking libpam-radius-auth (from .../libpam-radius-auth_1.3.16-4.4_amd64.deb) ...
Setting up libpam-radius-auth (1.3.16-4.4) ...

Now that the module is installed, it’s time to edit configuration files:

root@localhost:~# vi /etc/pam_radius_auth.conf

My default configuration file had two invalid entries defined to show the format. One of two entries in my configuration file was for 127.0.0.1 with a comment below it that read “having localhost in your radius configuration is a Good Thing”. I don’t know what that is supposed to mean, but don’t leave it in the configuration as we have no Radius server running on the local machine.

After removing the existing (sample) entries and replacing with valid server entries, which contained server[:port], shared_secret, and timeout (separated by tab) – save and close the file. A particular detail to note is that initially I set the timeout value to the displayed default of 3 (seconds). However, I experienced authentication failures until I changed that value to 5 (seconds) – after noticing timeout messages in /var/log/auth.log.

Next, we need to modify a PAM configuration file in order to specify the use of the RADIUS module when authentication occurs. Note: There are several services that make use of the PAM system for authentication. Therefore, by doing what I am about to explain could cause negative impact on an application that uses PAM to authenticate users. Further research should be performed to determine which configuration file the following commands should be placed in, based on what you want to secure.

In this example, there are no applications running that need auth services provided by PAM (such as an FTP server, HTTP server, SAMBA, etc). The goal is to define the use of a global policy that uses the RADIUS module for central authentication. If you wanted to only secure a particular service (like ssh logins for administrator shell access via sshd), a different file other than the following can be modified so to not disrupt any other PAM using applications installed on the machine.

Edit the /etc/pam.d/common-auth configuration file:

root@localhost:/etc/pam.d# vi common-auth

First, find the following line in the configuration:

auth	required	pam_unix.so nullok_secure

Insert a new line BEFORE/ABOVE the previous line and paste the following line into the file.

auth	sufficient	pam_radius_auth.so

Save and exit the file. The previous addition to the common-auth file tells PAM to use the RADIUS module for authentication first (since it is listed first in the configuration). By specifying ‘sufficient’ in our entry, PAM determines that a successful auth using this module is satisfactory, therefore no other modules defined in the configuration file need to be processed. However, if there is a failure from this module (user didn’t exist on RADIUS server), then continue processing entries in this configuration file. Note: By configuring this way, any locally defined users on the system will still authenticate successfully. Therefore, it is advised to only have local ‘emergency accounts’ defined, in case the machine completely looses communications with all configured RADIUS servers – you would still be able to log in with a local user. If you adopt this policy, obviously the people who know the credentials to the locally defined account(s) should be minimal – in order to force the use of individual (RADIUS defined) accounts.

Next, edit the /etc/pam.d/common-account file

root@localhost:/etc/pam.d# vi common-account

Find the line:

account	required	pam_unix.so

Insert the following BEFORE/ABOVE the previous line:

account	required	pam_radius_auth.so

Save and exit the file. The previous addition to the common-account file is to tell PAM to use the RADIUS module for any authorization requirement (like permitting access to a service based on time of day, etc.), prior to checking the local database. By specifying ‘required’ in our entry, PAM determines that the success of the module is required for the module-type facility (in this case authorization is the module-type) to succeed.

Next edit the /etc/pam.d/common-session configuration file:

root@localhost:/etc/pam.d# vi common-session

Find the line:

session	required	pam_unix.so

Insert the following lines BEFORE/ABOVE the previous line:

session	required	pam_radius_auth.so
session	required	pam_mkhomedir.so	skel=/etc/skel/	umask=0022

Save and exit the file. The previous addition to the common-session file is to define tasks to be performed at the start and end of a user control of a service. By specifying ‘required’ in our entry, PAM determines that the success of the module is required for the module-type facility (in this case services is the module-type) to succeed.

As you can see, we added a second module (pam_mkhomedir.so) to the common-session configuration file. This is required in order to have a home directory available for a RADIUS authenticated user. The module will run after a successful authentication and create the user home directory in /etc/skel with the appropriate permissions.

That will complete the configuration setup. There is one final step left that has to be performed for every user that will login to the system via RADIUS. Because RADIUS doesn’t provide a directory service, we have to have UID and GID information pre-populated on our system. This is accomplished by creating the username and groupname on the local system, which will assign the necessary unique user ID and group ID values (numbers).

For example, a user that needs to authenticate via radius using a login id of johnh (that belongs to an associated group called johnh) needs to have the following performed on the local system:

useradd johnh

That will do it, the user will now have an entry that is created in /etc/passwd and /etc/group with an automatically created (unique) ID number.