One time password are now spread in a lot of web services. They are valid only for a session and therefore even if intercept they can be used only once. Two methods are normalised by the Initiative For Open Authentication (OATH):
- time based one-time password algorithm (TOTP) that is based on the combination of time and a shared secret to generate the unique password.
- HMAC-based one-time password algorithm (HOTP) that is based on the combination of number of connection and a shared secret to generate the unique password.
To be able to use it, the user will need to have an application most of the time on her phone that generate the code asked by the server. The two algorithms are freely available as open standard and therefore numerous application are available to use them. The most known one is Google Authenticator That provide both a PAM module (for the setting on the server) and a phone application (for the user). However other phone application are available such as FreeOTP
Installation of the PAM module
Google developed a PAM module implementing the OATH-TOTP and OATH-HOTP. Its installation and configuration is simple. Since it is available in Debian repository to install it:
# apt install libpam-google-authenticator
After installation to use it on any PAM authentication module you need to a open the correct file and add the following line:
auth required pam_google_authenticator.so nullok
The nullok parameter allow the connection of the user without two factor
authentication setup to connect normally.
Activation for su
Only need to madify the su PAM module in /etc/pam.d/su. Add the
pam_google_authenticator line after pam_rootok.so
# This allows root to su without passwords (normal operation)
auth sufficient pam_rootok.so
auth required pam_google_authenticator.so nullok
Activation for SSH server
First configure SSH PAM authentication module in /etc/pam.d/sshd. Had at
the end of the file:
auth required pam_google_authenticator.so nullok
In /etc/ssh/sshd_config change the value of
ChallengeResponseAuthentication from no to yes.
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication yes
By default the authentication will be managed as follow:
- User that connect with a SSH key will log as usual
- User that log with a password will in addition need to respond to a OTP challenge.
$ ssh user@server
Password:
Verification code:
Setting TOTP for an user
We will see here how to setup TOTP parameter for an user. It will be used by any
PAM module where pam_google_authenticator is activated.
Login as the desired user and run google-authenticator
$ google-authenticator
Do you want authentication tokens to be time-based (y/n)
Answer yes to the first question to have time based on one time password (TOTP) or no to get HMAC-based one time password (HOTP). It will generate the shared code and display in your console a QR code ready to be scanned by your phone. If not displayed, you can open the link given to open the QR code. An example output:
https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/user@server%3Fsecret%3DHENVXKRO4RFDSRDK
Your new secret key is: HENVXKRO4RFDSRDK
Your verification code is 580768
Your emergency scratch codes are:
28520578
41297079
99231833
99978459
29834705
In addition to the key it give you a verification code. This is the code generated at the time of QR code generation to be sure that is correctly entered. It give you also 5 emergency scratch codes that can be used at any time to login. They need of course to stored in a safe place.
Do you want me to update your "/home/user/.google_authenticator" file (y/n)
Answer yes to allow the module to setup the needed file for the authentication. Your secret key the different parameters and the emergency scratch codes will be saved in this file.
Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n)
Answer yes to allow only one utilisation of each password. It will block you to login twice in less than 30 seconds (default time resolution for password generation).
By default, tokens are good for 30 seconds and in order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with poor
time synchronization, you can increase the window from its default
size of 1:30min to about 4min. Do you want to do so (y/n)
Answer no, the allowed timing of the password will be +/- 30 seconds. For most of the case it will be largely sufficient.
If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y
Answer yes, it does not cost so much to strength the access even if the server already have some protection against brute force attack (like fail2ban).