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
Win an iPhone 6
Enter to Win
|Geek Hide-away in Guatemala - Stay for Free!||Nov 26, 2015|
|Microsoft and Linux: True Romance or Toxic Love?||Nov 25, 2015|
|Non-Linux FOSS: Install Windows? Yeah, Open Source Can Do That.||Nov 24, 2015|
|Cipher Security: How to harden TLS and SSH||Nov 23, 2015|
|Web Stores Held Hostage||Nov 19, 2015|
|diff -u: What's New in Kernel Development||Nov 17, 2015|
- Cipher Security: How to harden TLS and SSH
- Microsoft and Linux: True Romance or Toxic Love?
- Non-Linux FOSS: Install Windows? Yeah, Open Source Can Do That.
- Web Stores Held Hostage
- Firefox's New Feature for Tighter Security
- Geek Hide-away in Guatemala - Stay for Free!
- PuppetLabs Introduces Application Orchestration
- It's a Bird. It's Another Bird!
- diff -u: What's New in Kernel Development
- IBM LinuxONE Provides New Options for Linux Deployment