That I am lazy if it comes to typing much shouldn’t be a secret by now, but mentioning it here might be wrong too – but it was the main cause for doing some research for an alternative login method. Fingerprints may sound fun, but if it comes to security or if you need to pass on the password to someone…

But as you might guess, I’m not the only one facing that problem – there’s even a nice packet waiting for us, called sys-auth/pam_usb. If you’re using gentoo linux, you can simply emerge it after unmasking a current version. A version number below 0.4.1 isn’t recommended at all.

# echo “sys-auth/pam_usb” >> /etc/portage/package.keywords
# emerge -av “>=sys-auth/pam_usb-0.4.1”

As the compile finishes, we want to go to the funny part – configuration. As a test USB device I have chosen to use my SanDisk Corp. Cruzer Titanium. But let’s start right in using the on-board tools delivered with the package:

# pamusb-conf –add-device MySecretDevice
Please select the device you wish to add.
* Using “SanDisk Corp. Cruzer Titanium (SNDKXXXXXXXXXXXXXXXX)” (only option)
Which volume would you like to use for storing data ?
* Using “/dev/sdb1 (UUID: <6F6B-42FC>)” (only option)
Name : MySecretDevice
Vendor : SanDisk Corp.
Model : Cruzer Titanium
Serial : SNDKXXXXXXXXXXXXXXXX
Volume UUID : 6F6B-42FC (/dev/sdb1)
Save to /etc/pamusb.conf ?
[Y/n] y
Done.

If things work the same way they do on my howto, the USB stick is now set up for authentication in general. Now let’s add users. I’d say using root is pretty cool – so let’s try.

# pamusb-conf –add-user root
Which device would you like to use for authentication ?
* Using “MyDevice” (only option)
User : root
Device : MySecretDevice
Save to /etc/pamusb.conf ?
[Y/n] y
Done.

Theoretically our user root is configured now for usb authentification. But as it’s an important system user, let’s make sure, things are working:

# pamusb-check root
* Authentication request for user “root” (pamusb-check)
* Device “MySecretDevice” is connected (good).
* Performing one time pad verification…
* Verification match, updating one time pads…
* Access granted.

Well – the basic stuff is done. Now let’s start with the difficult part: we’re dangling on PAM. As I want to make the changes system wide, I’m working with the file /etc/pam.d/system-auth where I am looking for the line saying

auth required pam_unix.so nullok_secure

which I’m changing to

auth sufficient pam_usb.so
auth required pam_unix.so nullok_secure

A test follows.

pavilion $ su
* pam_usb v.0.4.3
* Authentication request for user “root” (su)
* Device “MySecretDevice” is connected (good).
* Performing one time pad verification…
* Verification match, updating one time pads…
* Access granted.

And hooray, it works. Regarding the different pam-implementations, you may even get it to work with kdm, gdm and all that jazz using it. But there’s a funny thing I am still missing: automatic locking of the screen on removing the device.

Believe it or not – there’s even a solution for our problem. It’s called pamusb-agent. The config for it could look that way if you’re using KDE:

    MySecretDevice
    dcop kdesktop KScreensaverIface lock
    dcop kdesktop KScreensaverIface quit
  

For making things roll, just ensure it’s started on KDE startup:

cd ~/.kde/Autostart
ln -s /usr/bin/pamusb-agent pamusb-agent

And that’s it.