How To: Setting Up Google's Two-Factor Authentication In Linux
This is a guest diary written by Jeff Singleton. If you are interested in contributing a guest diary, please ask via our contact form
---------------
We can already use two-step authentication in GMail with the Google Authenticator Android app. The idea is creating a secret key shared between the service and the Android app, so every 30 seconds we get a randomly generated token on Android that must be provided to login in addition to the password. That token is only valid in that 30s time frame.
Since this provides a nice second security layer to our logins, why don't take advantage of it also in our Linux box?
We'll need two things to get started:
Install Google Authenticator on our Android, iOS or Blackberry phone.
Install the PAM on our Linux box
The first step is frivolous, so we will just move on to the second one.
To setup two-factor authentication for your Linux server you will need to download and compile the PAM module for your system. The examples here will be based on CentOS 6, but it should be easy enough to figure out the equivalents for whatever distribution you happen to be using. Here is a link with similar steps for Ubuntu/Debian or any OS using Aptitude.
$ sudo yum install pam-devel |
Once the PAM module and the command-line google-authenticator application are installed, you need to edit the /etc/pam.d/sshd file to add the below code to the very top of the file.
auth required pam_sepermit.so
auth required pam_google_authenticator.so
auth include password-auth
Additionally, you may wish to add the two-step authentication to your display manager (kdm, gdm, or lightdm). Depending on your distro you might be using a different login manager. Pick and edit the correct file among these:
· /etc/pam.d/gdm
· /etc/pam.d/lightdm
· /etc/pam.d/kdm
Add this line at the bottom:
auth required pam_google_authenticator.so
Once we have that installed we will run this command with the user we want to use two-step authentication with. If we want to use it for several users we will have to run it once with each of them, since it generates a unique secret key each time:
% google-authenticator Do you want me to update your "~/.google_authenticator" file (y/n) y https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/user@server%3Fsecret%3DABCD12E3FGHIJKLMN Your new secret key is: ABCD12E3FGHIJKLMN Your verification code is 98765432 Your emergency scratch codes are:
01234567 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) y 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) n 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 |
Once you see the above text in your terminal window, the very next thing you will do is launch your web browser and point it to the URL shows towards the top of the text above.
You should now see is a big QR code. Open your Google Authenticator app on your phone of choice and hit the menu button then select "Scan barcode". Point the camera to the QR code on the screen and you'll get a new item on the Google Authenticator main screen with an ID for the user and computer and the generated token below, along with a counter showing how much time is left for the code to expire.
TIP: time is very important, so your Linux server should have an NTP client installed in order to keep the time accurate. You should definitely keep an eye on this, and if you have any trouble you may have to open the window size as noted by google-authenticator.
TIP: You will also need to edit /etc/ssh/sshd_config to enable "ChallengeResponseAuthentication" and "UsePAM" (set them both to "yes").
Finally, you will restart sshd to commit the changes you just made. When this is done, try logging into the system via SSH:
% ssh <your server> Verification code: Password: Last login: Tue May 10 11:54:21 2011 from client.example.com |
You must provide the verification code as presented by your phone in order to log in. Even if the password is known, without the verification code, the login will fail.
Important: you will not be able to use this method if you use ssh private/public keys as the two are mutually exclusive.
The two step authentication will keep users out of you box as long as they don't also have access to your phone, but you shouldn't forget that there's no way to really secure a box if the attacker has physical access to it.
The secret key is stored in your home folder. The attacker could boot your box from a Live CD, get the key and generate tokens and have access to your Linux server.
Then again same thing holds true for you user password so that's not to say that two step authentication is not secure, it's just that is has the same problems as any other login method when it comes with physically accessible machines.
Comments
Anonymous
Aug 1st 2013
1 decade ago
Not with SSH auth. But you could use Allow/Deny statements in the SSH configuration to create a dedicated user for SSH'ing in with public key.
That is; create a user with a restricted shell that you SSH in as, so the only allowed command is 'SU' to certain users.
Then with SSHD configured to only allow public key auth; you require (1) Public key or Certificated based authentication to SSH; after logged in (2) a SU password, and (3) the google authenticator verification code.
Which is basically 3-factor authentication, since....
(1) Public Key -- Some location that you are located at (You're logged into a workstation that has the private key corresponding to the SSH public key certificate installed; preferably in a non-exportable certificate keystore, so the SSH key cannot easily be stolen).
Anonymous
Aug 1st 2013
1 decade ago
I made it work with OpenSSH 6.2p1.
Here is my configuration
in sshd_config
Match User somebody
AuthenticationMethods "publickey"
Match User "*,!somebody"
AuthenticationMethods "publickey,keyboard-interactive"
Somebody will use public/private keys for authentication.
Other users will use public/private keys + google autneticator
change sshd pam configuration
[root@test]# pwd
/etc/pam.d
[root@test]# cat sshd
#%PAM-1.0
auth required pam_sepermit.so
#auth include password-auth
auth required pam_google_authenticator.so
account required pam_nologin.so
account include password-auth
password include password-auth
# pam_selinux.so close should be the first session rule
....
Anonymous
Aug 2nd 2013
1 decade ago
Anonymous
Aug 2nd 2013
1 decade ago
The Google authenticator on the iPhone does not require a password. It does just rely on the screen lock password. Of course, these tokens are vulnerable to hacked devices as well, which is why for high security access, hard-tokens should be used.
Anonymous
Aug 2nd 2013
1 decade ago
Because when I try to login, its asks me verification code, which code should I provide here ?
Anonymous
Sep 17th 2013
1 decade ago
<a href="http://www.bexinhshop.vn" title="mua s?m qu?n áo tr? em">mua s?m qu?n áo tr? em</a>
Anonymous
May 26th 2014
1 decade ago