Configuring One-Time Password Authentication with OTPW
In particular, OTPW provides:
Two-factor authentication, consisting of a "prefix password" and a set of autogenerated, disposable suffixes. Even if the list of suffixes falls into the wrong hands, brute force is necessary without the prefix password.
Protection against certain race conditions and man-in-the-middle attacks through the use of password locks and triplet challenges.
Shared-filesystem support. Because OTPW checks passwords against a list of hashed values stored in a user's home directory, one password list will work for all systems mounting the same $HOME directory.
Next, I cover installing and using OTPW, with a special focus on integration with OpenSSH.
To make use of OTPW, you need two binaries: otpw-bin and libpam-otpw. With Debian and Ubuntu, installation is as easy as:
sudo apt-get install otpw-bin libpam-otpw
If your distribution does not provide OTPW, you can download the source directly from the author's home page. The source tarball does not use GNU autoconf, so you will need to compile and install the binaries manually in accordance with the author's instructions.
The next step in preparing the system for OTPW is configuration of libpam-otpw. A full treatment of PAM is outside the scope of this article, but I cover the most common use cases here.
Changing your PAM configuration can lock you out of your workstation or server, so it's a good idea to keep your existing terminal open until you're sure that things are working correctly. If you have console access, keep a bootable distribution or rescue disk handy. See the Testing One-Time Password Authentication with SSH sidebar for more information about testing PAM over SSH.
Testing One-Time Password Authentication with SSH
If you are configuring a remote system for OTPW, you should test your PAM stack without closing your current SSH connection. Remember, if you make a mistake with your PAM configuration, you may be unable to authenticate—even with console access—so keep a bootable distribution, such as Knoppix, SystemRescueCD or Finnix handy just in case. Meanwhile, existing logins remain unaffected because they already are authenticated.
In order to test the PAM stack properly, you can't re-use your existing SSH connection. Most recent distributions support SSH multiplexing and persistent connections out of the box, so explicitly disable these options for testing.
In addition, SSH prefers public key authentication by default. So, in order to test OTPW authentication, public key authentication needs to be temporarily disabled too.
The following invocation enables accurate testing of the SSH PAM stack, without making any system changes:
read -p 'Hostname: ' REMOTE_HOST && SSH_AGENT_PID= SSH_AUTH_SOCK= \ ssh \ -o PreferredAuthentications=keyboard-interactive \ -o ControlPersist=no \ -o ControlPath=none \ "$REMOTE_HOST"
Once you have confidence that OTPW is working correctly, you also should verify that your other authentication mechanisms (namely SSH public keys and normal system passwords) continue to work as expected.
The easiest way to enable OTPW is to put it immediately above
in your common-auth configuration file:
# /etc/pam.d/common-auth auth sufficient pam_otpw.so session optional pam_otpw.so auth sufficient pam_unix.so nullok_secure auth required pam_deny.so
The order of the PAM libraries is very important. When placing OTPW first, users with an ~/.otpw file are prompted for a one-time password first, allowing fallback to standard system passwords if the OTPW login fails. Users without a ~/.otpw file simply will see the standard password prompt.
Todd A. Jacobs is a veteran IT consultant with a passion for all things Linux. He spends entirely too much time making systems do things they were never designed to do.