When you look down the list of supported Linux distributions officially supported by RSA there are numerous omissions. Fear not for while they may not be officially supported it doesn't mean you can't make 2FA work. For this example we used Debian, PAM and RSA via radius to effect 2FA for SSH access. The end result was even more pleasing as we managed to get granularity across users and services. Read on....
Acknowledgement
Firstly I would like to acknowledge Jacob Appelbaum for his excellent article which is a good starting point for this endeavor.
This article works well and essentially gives us the following:
Note that this will use new radius and accounting so allow ports UDP 1842 and UDP 1840 from the source Linux hosts to your RSA AM deployment.
Deploy by User
Note this first method via blanking out passwords is a bit of a quick dodge and useful for testing purposes, I will publish another method shortly.
The requirement to have some users using 2FA and others not is not uncommon. So an easy way to do this is to blank out passwords for those users who will be using 2FA via RSA such as privileged accounts. When combined with the following configuration files the effect is to require 2FA for those with no local password or password for those who have one.
/etc/pam.d/common-auth
#
# /etc/pam.d/common-auth - authentication settings common to all
# services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
# traditional Unix authentication mechanisms.
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.
# here are the per-package modules (the "Primary" block)
#auth [success=1 default=ignore] pam_unix.so nullok_secure
# here's the fallback if no module succeeds
auth sufficient pam_unix.so nullok_secure
auth required pam_radius_auth.so debug
account required pam_radius_auth.so
session required pam_radius_auth.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
# Generic unix uth services below
#auth required pam_unix.so nullok_secure
# Automatic home directory creation
session required pam_mkhomedir.so skel=/etc/skel/ umask=0022 silent
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config
pam_radius_auth.conf
# pam_radius_auth configuration file. Copy to: /etc/raddb/server
#
# For proper security, this file SHOULD have permissions 0600,
# that is readable by root, and NO ONE else. If anyone other than
# root can read this file, then they can spoof responses from the server!
#
# There are 3 fields per line in this file. There may be multiple
# lines. Blank lines or lines beginning with '#' are treated as
# comments, and are ignored. The fields are:
#
# server[:port] secret [timeout]
#
# the port name or number is optional. The default port name is
# "radius", and is looked up from /etc/services The timeout field is
# optional. The default timeout is 3 seconds.
#
# If multiple RADIUS server lines exist, they are tried in order. The
# first server to return success or failure causes the module to return
# success or failure. Only if a server fails to response is it skipped,
# and the next server in turn is used.
#
# The timeout field controls how many seconds the module waits before
# deciding that the server has failed to respond.
#
# server[:port] shared_secret timeout (s)
127.0.0.1 secret 1
x.y.z.w sharedsecretpassword1 10
a.b.c.d sharedsecretpassword2 10
#
# having localhost in your radius configuration is a Good Thing.
#
# See the INSTALL file for pam.conf hints.
Deploy by Service
This is well documented in a number of areas so I will refer to one of them below as a good source for creating the correct files to authenticate for a specific service.
Hope this is of value...