Two factor authentication is increasingly becoming a strongly recommended way of protecting user accounts in web applications from attackers by requiring a second method of authentication in addition to the standard username and password pair.

Although two factor authentication can encompass a wide range of techniques like biometrics or smart cards, the most commonly deployed technique in web applications is the one time password. If you have used applications like Gmail, you are probably familiar with the one time password generated by the Google Authenticator app that’s available on iOS or Android devices.

The algorithm used for the one time password in the Google Authenticator app is known as the Time-based One-Time Password (TOTP) algorithm. The TOTP algorithm is a standard algorithm approved by the IETF in (RFC 6238) totp-rfc.


You need to download Google Authenticator app that generates 2-step verification codes on your phone or desktop. Install Google Authenticator before you install anything else on your Android device/iPhone/iPad/BlackBerry/Firefox devices.

Install Google Authenticator on a Fedora Linux

It is a little known fact that you can use the TOTP algorithm to secure your user accounts in Linux systems. This article will walk you through the steps necessary. While the exact commands will be for Fedora 20, the TOTP algorithm can be deployed to any Linux distro with a little modification.

TOTP can be configured on Linux systems with a simple PAM that Google released. Installing it on Fedora is simple. Simply run the following yum command:

yum install google-authenticator
## OR ##
sudo yum install google-authenticator

Configure Google Authenticator on a Fedora Linux

Next, run the following command with the user you want to enable two factor authenticator for:


You will be prompted for some configurations. Scan the QRcode that appears with the Google Authenticator app:

Fig.01: Google Authenticator app qr code for Linux

Fig.01: Google Authenticator app qr code for Linux

Save the backup codes listed somewhere safe. They will allow you to regain access if you lose your phone with the Authenticator app:
Fig.02: Google Authenticator Backup codes for Linux

Fig.02: Google Authenticator Backup codes for Linux

Unless you have a good reason to, the defaults presented are sane. Just enter "y" for them:
Fig.03: Google Authenticator Linux options

Fig.03: Google Authenticator Linux options

Finally, add the following line to /etc/pam.d/gdm-password file:

auth required

Save and close the file. On your next login, you should see a prompt for a verification code:

Fig.04: Google Authenticator code to protect Linux desktop login

Fig.04: Google Authenticator code to protect Linux desktop login

Enter the one time password generated by the Google Authenticator app and you will be logged in:
Fig.05: Firefox based Google Authenticator App in action

Fig.05: Firefox based Google Authenticator App in action

How can I get Google Authenticator tokens?

You can download app from the following location as per your device/browser to retrieve Google Authenticator tokens:

  1. Google Authenticator Apple iOS app – Works with 2-Step Verification for your Google Account to provide an additional layer of security when signing in.
  2. Google Authenticator android app – Generates 2-step verification codes on your phone.
  3. Google Authenticator Firefox app – Generates TOTP tokens when multi-factor authentication using Firefox.
  4. See the list of all Google Authenticator apps

Secure your OpenSSH server using two-step authentication on a Fedora / RHEL / CentOS Linux

This can be applied to SSH logins as well. Although disabling password logins for SSH and limiting it to SSH keys only is a good idea, this might not be possible in some environments. In such cases, adding two factor authentication can be a good compromise. Adding TOTP to SSH is easy as well.

Assuming you have already went through the above configurations, only two other steps is required.

First, add the following line to /etc/pam.d/sshd:

auth required

Next, ensure that the /etc/ssh/sshd_config has the following line:

ChallengeResponseAuthentication yes

Save and close the file. Restart the sshd service:

sudo service sshd restart
## OR ##
sudo systemctl restart sshd.service

On your next SSH login, you should be promoted for a verification code in addition to the usual password:

login as: nixcraft
Verification code: 

This article was contributed by Terry Chia. You can too contribute to nixCraft.

πŸ₯Ί Was this helpful? Please add a comment to show your appreciation or feedback.

nixCrat Tux Pixel Penguin
Hi! 🀠
I'm Vivek Gite, and I write about Linux, macOS, Unix, IT, programming, infosec, and open source. Subscribe to my RSS feed or email newsletter for updates.

17 comments… add one
  • Raphael Oct 1, 2014 @ 13:00

    Just a hint as Google Authenticator Android app started to fail on my Wiko with Android kitkat (4.4.2) generating always wrong codes ! I found on some blog that there is a very good workaround using FreeOTP which is an app maintained by Redhat and doing the very same job.

    • Jean-Francois Messier Oct 1, 2014 @ 17:09

      In all those time-based authenticators, we have to remember that there is a setting for a time difference tolerance. The larger the tolerance is, the less secure your system will be as it will accept more codes, at any moment. And the time difference between the server and the device that carries the shared secret, is usually not compensatedon the future authentications, which means that if at the beginning there is a difference of 10 seconds between the clocks and the difference grows, we reach a point where the difference is too big the accepted time difference. The best thing is to use your cell phone which is always synced with your provider and keep your server in sync with some NTP server. Then, the time difference should remain the same.

  • Tim Oct 1, 2014 @ 13:35

    This is so cool!

  • sapk Oct 1, 2014 @ 14:12

    Il y a authy qui propose la mΓͺme chose :
    avec un simple script bash qui fait appel Γ  leur api.
    Et sinon y a aussi duo un peu plus complet :

    • Tsi Hambaka Oct 2, 2014 @ 17:57


  • BigTimmay Oct 1, 2014 @ 14:15


    • Guest Mar 12, 2015 @ 19:57

      I started working from home, by working various simple jobs which only requires from you desktop or laptop computer and internet connection and I couldn’t be happier… It’s been 6 months since i started this and i got paid in total $36k… Basicly i get paid about 80 bucks/hourly and work for 3 to 4 h a day.Best part to whole this thing is that you can manage time when you work and for how long as you like and you get paid weekly.

  • LCM Oct 2, 2014 @ 11:04

    After configuring the Fedora epel repository, there are no packages named

    google-authenticator. Did I miss something?

  • benny Oct 2, 2014 @ 14:16

    I already set up the 2-way authentication with my gmail account. How can I use my existing one to protect my linux login as well?

    • Sir_Mr_Bman Oct 6, 2014 @ 17:16

      I don’t think you can.

      Because of the way that the authentication works, it only protects 1 login. Since all google services use the same accounts service, this works in their case. Unless you make your server a google service, I don’t think you can get the login to work.

  • Dan Hamilton Oct 10, 2014 @ 13:12

    While I may have used google to log on here and make this post, I’m not sure I agree with having a third party like google handle authentication on an enterprise or even a personal network. Besides, isn’t RSA key authentication (done correctly with password protected keys and a rotation schedule) a valid form of two-factor authentication already, built right in to OpenSSH? It’s something you have (a digital private key) combined with something you know (the password to unlock it). For paranoia’s sake you could even store the key on a hardware encrypted USB thumb drive if you wanted, all the while not having to worry about whether google will shut down this service or any other concerns brought on by allowing a third party to stand in the middle as a dependency to accessing your systems.

    The ultimate question I have is, why do this? It may be arguably more secure, but at what cost and to what end?

    • Max Roeleveld Oct 20, 2014 @ 8:49

      Unless I’m really missing something, the actual authentication is not done through Google or any other third party; it just happens to use the app that is made by Google. Once setup, Google can disable the service all they want, you’ve already set up a link between a host and an authenticator app.

      I think the Facebook mobile app has a number generator as well, and I’m sure there’s others. All those apps do, and again this is based on my knowledge which may or may not be complete, is generate random yet somehow predictable numbers, just like those Security Token keyring fobs do.

  • Marvin R. Oct 22, 2014 @ 14:20

    This sounds really awesome. But I use Ubuntu and Debian… this article only mentions Red Hat based distributions. So my question: Will it also work the same way on Ubuntu? Or are there differences?

    • jon doe Nov 3, 2016 @ 1:40

      It’s Linux, so other than the install, no it will not be different.

  • no Jan 4, 2015 @ 15:02

    error. no google in your distro. warning

    • linacostaa Mar 21, 2015 @ 17:52


  • MarcoT Mar 1, 2023 @ 14:17

    Hi there, I found this topic very interesting and gave it a shot with a vanilla Fedora 37 VM. Unfortunately whit the code of the Google calculator I cannot login. So I tried 1Password too. Same result.
    Any chance there is an update to the procedure possible to make it work (again)?
    -Thanks Marco

Leave a Reply

Your email address will not be published. Required fields are marked *

Use HTML <pre>...</pre> for code samples. Your comment will appear only after approval by the site admin.