I’ve many distributed Linux instances across several clouds, be them global, such as Amazon or Digital Ocean, or regional clouds such as TeutoStack or Enter.
Probably many of you are facing the same issue: having a consistent UNIX identity across all multiple instances. While in an ideal world LDAP would be a perfect choice, letting LDAP open to the wild Internet is not a great idea.
So, how to solve this issue, while being secure? The trick is to use the new NSS module for SecurePass.
While SecurePass has been traditionally used into the operating system just as a two factor authentication, the new beta release is capable of holding “extended attributes”, i.e. arbitrary information for each user profile.
We will use SecurePass to authenticate users and store Unix information with this new capability. In detail, we will:
- Use PAM to authenticate the user via RADIUS
- Use the new NSS module for SecurePass to have a consistent UID/GID/….
SecurePass and extended attributes
The next generation of SecurePass (currently in beta) is capable of storing arbitrary data for each profile. This is called “Extended Attributes” (or xattrs) and -as you can imagine- is organized as key/value pair.
You will need the SecurePass tools to be able to modify users’ extended attributes. The new releases of Debian Jessie and Ubuntu Vivid Vervet have a package for it, just:
# apt-get install securepass-tools
For other distributions or previous releases, there’s a python package (PIP) available. Make sure that you have pycurl installed and then:
# pip install securepass-tools
While SecurePass tools allow local configuration file, we highly recommend for this tutorial to create a global /etc/securepass.conf, so that it will be useful for the NSS module. The configuration file looks like:
[default] app_id = xxxxx app_secret = xxxx endpoint = https://beta.secure-pass.net/
Where app_id and app_secrets are valid API keys to access SecurePass beta.
Through the command line, we will be able to set UID, GID and all the required Unix attributes for each user:
# sp-user-xattrs user@domain.net set posixuid 1000
While posixuid is the bare minimum attribute to have a Unix login, the following attributes are valid:
- posixuid → UID of the user
- posixgid → GID of the user
- posixhomedir → Home directory
- posixshell → Desired shell
- posixgecos → Gecos (defaults to username)
Install and Configure NSS SecurePass
In a similar way to the tools, Debian Jessie and Ubuntu Vivid Vervet have native package for SecurePass:
# apt-get install libnss-securepass
For previous releases of Debian and Ubuntu can still run the NSS module, as well as CentOS and RHEL. Download the sources from:
https://github.com/garlsecurity/nss_securepass
Then:
./configure make make install (Debian/Ubuntu Only)
For CentOS/RHEL/Fedora you will need to copy files in the right place:
/usr/bin/install -c -o root -g root libnss_sp.so.2 /usr/lib64/libnss_sp.so.2 ln -sf libnss_sp.so.2 /usr/lib64/libnss_sp.so
The /etc/securepass.conf configuration file should be extended to hold defaults for NSS by creating an [nss] section as follows:
[nss] realm = company.net default_gid = 100 default_home = "/home" default_shell = "/bin/bash"
This will create defaults in case values other than posixuid are not being used. We need to configure the Name Service Switch (NSS) to use SecurePass. We will change the /etc/nsswitch.conf by adding “sp” to the passwd entry as follows:
$ grep sp /etc/nsswitch.conf passwd: files sp
Double check that NSS is picking up our new SecurePass configuration by querying the passwd entries as follows:
$ getent passwd user user:x:1000:100:My User:/home/user:/bin/bash
$ id user uid=1000(user) gid=100(users) groups=100(users)
Using this setup by itself wouldn’t allow users to login to a system because the password is missing. We will use SecurePass’ authentication to access the remote machine.
Configure PAM for SecurePass
On Debian/Ubuntu, install the RADIUS PAM module with:
# apt-get install libpam-radius-auth
If you are using CentOS or RHEL, you need to have the EPEL repository configured. In order to activate EPEL, follow the instructions on http://fedoraproject.org/wiki/EPEL
Be aware that this has not being tested with SE-Linux enabled (check off or permissive).
On CentOS/RHEL, install the RADIUS PAM module with:
# yum -y install pam_radius
Note: as per the time of writing, EPEL 7 is still in beta and does not contain the Radius PAM module. A request has been filed through RedHat’s Bugzilla to include this package also in EPEL 7
Configure SecurePass with your RADIUS device. We only need to set the public IP Address of the server, a fully qualified domain name (FQDN), and the secret password for the radius authentication. In case of the server being under NAT, specify the public IP address that will be translated into it. After completion we get a small recap of the already created device. For the sake of example, we use “secret” as our secret password.
Configure the RADIUS PAM module accordingly, i.e. open /etc/pam_radius.conf and add the following lines:
radius1.secure-pass.net secret 3 radius2.secure-pass.net secret 3
Of course the “secret” is the same we have set up on the SecurePass administration interface. Beyond this point we need to configure the PAM to correct manage the authentication.
In CentOS, open the configuration file /etc/pam.d/password-auth-ac; in Debian/Ubuntu open the /etc/pam.d/common-auth configuration and make sure that pam_radius_auth.so is in the list.
auth required pam_env.so auth sufficient pam_radius_auth.so try_first_pass auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so
Conclusions
Handling many distributed Linux poses several challenges, from software updates to identity management and central logging. In a cloud scenario, it is not always applicable to use traditional enterprise solutions, but new tools might become very handy.
To freely subscribe to securepass beta, join SecurePass on: http://www.secure-pass.net/open
And then send an e-mail to info@garl.ch requesting beta access.
The original article is on Alessio Treglia’s blog
