where $USER and $GROUP are the user and group that own the other files in /var/log. Once the file has been created and ownership has been set, simply change the permissions on the file to reflect those of the other files in /var/log by using this command:
chmod 0600 /var/log/pam_usb.log
More advanced users may want to configure a log rotation schedule for the pam_usb.log or even change the file to be append-only with chattr. Those options are left as exercises for the reader to explore.
Now that the log file has been set up, we need to back up the existing PAM configuration files. This is an important step, so do not skip it. On most systems, the PAM configuration files are stored in /etc/pam.d. As root, make a backup copy with:
cp -rfp /etc/pam.d ~/pam.d/
For testing sake, we are working with the PAM configuration for su, because it is the easiest PAM-aware application to test. As a precautionary method, you should keep a root shell open and accessible so that if a mistake is made in configuring pam_usb, you are able to rescue yourself by overwriting the edited configuration files with backups from your ~/pam.d. You also need to know what filesystem is used on the USB drive(s) you will be configuring. In an ideal world, we can use mount to do the work for us, provided /mnt/usb exists and your USB drive is on /dev/sda. Use:
mount /dev/sda1 /mnt/usb
to see what filesystem is on the drive—the filesystem is listed in parentheses at the end of the line. Most USB drives use the vfat filesystem and do not have more than one partition. Thus, they are mountable with:
mount -t vfat /dev/sda1 /mnt/usb
Our first real step in configuring pam_usb is to alter the PAM-aware applications' PAM configuration file—this step is required for each application you want to use pam_usb to authenticate to. Because we're working with su for testing purposes, focus only on the /etc/pam.d/su file. Do not try to configure every PAM-aware application in a single mass-edit of your /etc/pam.d directory, or tears and sorrow surely will be your lot. The files in /etc/pam.d/ correspond to the applications they configure, so if you were to configure console logins or GNOME Display Manager logins, you would be concerned with /etc/pam.d/login and /etc/pam.d/gdm, respectively. The naming pattern for PAM's configuration files should be relatively self-evident. So, open /etc/pam.d/su in your favorite text editor and add the following line above the pam_unix line:
auth required pam_usb.so fs=vfat check_device=-1 \ check_if_mounted=-1 force_device=/dev/sda \ log_file=/var/log/pam_usb.log
If you do not include the above line before the pam_unix line, PAM never reaches the point of authenticating against the USB device. Instead, it is satisfied by the authentication that occurs through pam_unix, and it drops out of the authentication process.
A few options in the pam_usb configuration that need further explanation: the force_device option, the pam_usb mode, the filesystem of the device and the log file we're going to use.
pam_usb is capable of autodetecting which USB-attached device houses the authentication keys. By not specifying the force_device directive, pam_usb walks through all of the attached devices and looks for keys matching the specified user name. This is helpful if the machine has multiple USB devices that are assigned device names according to the order in which they were attached—the first device is /dev/sda, the second is sdb and so on. If you specify the force_device directive, you are not able to authenticate unless your USB drive is assigned the device name specified in the PAM configuration.
pam_usb supports three modes of operation: unique, alternative and additional. With unique mode, you can log in using your USB drive, but if it's not present it isn't possible to log in. This is achieved by commenting out pam_unix in $PAMDIR/login and adding the configuration line above. The alternative mode allows you to log in simply by plugging in your USB key. If the key is not present, the system prompts for a password. This is accomplished by leaving pam_unix intact, adding the above configuration line to the PAM configuration file above the pam_unix entry and changing the auth required bits of the line to read auth sufficient. To achieve a true two-factor authentication, you need to require both the user name/password pair and the USB key, which is how the configuration above is set.
Andrea Luzzardi also points out an alternative two-factor authentication that involves encrypting the private key stored on the USB drive, after which the key requires a password to be decrypted and used for authentication. pam_usb is capable of passing the password provided to PAM through to decrypt the private key, thus accomplishing two-factor authentication off of a single user name and password pair. Furthermore, this is accomplished while not compromising any of the security benefits of having two-factor authentication. This method of authentication is contingent on using the same password for the user account that was used to encrypt the private key used by pam_usb. To encrypt the private key used by pam_usb, simply use the usbadm tool to create the cryptographic token:
usbadm cipher /path/to/usb/filesystem \ username algorithm
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development