How to add 2FA to our SSH connections with Google Authenticator
In this Teratip, we will learn how to configure the Google Authenticator PAM module to our SSH (Secure Shell) server connections to add an extra layer of security and protect our systems and data from unauthorized access.
The Google Authenticator PAM module is a software component that integrates with the Linux PAM framework to provide two-factor authentication using the Google Authenticator app. It enables users to generate time-based one-time passwords (TOTPs) on their phones, which serve as the second factor for authentication.
Two-factor authentication (2FA) is a security measure that requires users to provide two different factors to verify their identity. These factors can include something they know (like a password), something they have (like a mobile device), or something they are (like a fingerprint). Combining the two factors adds an extra layer of security, making it significantly harder for attackers to gain unauthorized access.
Even if an attacker manages to obtain or guess the password, they would still need the second factor to authenticate successfully. This helps protect against various types of attacks, such as password cracking or phishing, and enhances overall security by requiring dual verification.
This is how it’s done:
Step # 1: Install Google Authenticator app
The first step will be installing the Google Authenticator app in our smartphone. It’s available for Android and IOS.
Step # 2: Install Google Authenticator PAM module
Secondly, we’ ll install the Google Authenticator PAM module.
On Debian/Ubuntu we can find this module in the repositories:
sudo apt install libpam-google-authenticator
Step # 3: SSH server configuration
After the installation of the requirements, we need to configure the ssh server to use the new PAM module. We can do it easily by editing some of the configuration files.
On /etc/pam.d/sshd add the following line:
auth required pam_google_authenticator.so
And on the /etc/ssh/sshd_config change the following option from ‘no’ to ‘yes’:
ChallengeResponseAuthentication yes
We need to restart the service to get the changes applied in our ssh server with:
sudo systemctl restart sshd.service
Finally, we just need to launch Google Authenticator command to start the configuration of the 2FA, this is by simply executing:
google-authenticator
This will trigger a few configuration questions to answer and the first one will generate a QR code, a secret key, and recovery codes. You will need to scan the QR code with the Google Authenticator previously installed on your phone:
Do you want authentication tokens to be time-based (y/n) y
After scanning the QR code the TOTP will start appearing on the app like this:
Step # 4: Answer context-specific questions
After this you have to answer the other questions based on your particular scenario:
Do you want me to update your "/home/facu/.google_authenticator" file? (y/n) y 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, a new token is generated every 30 seconds by the mobile app. 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. This allows for a time skew of up to 30 seconds between authentication server and client. If you experience problems with poor time synchronization, you can increase the window from its default size of 3 permitted codes (one previous code, the current code, the next code) to 17 permitted codes (the 8 previous codes, the current code, and the 8 next codes). This will permit for a time skew of up to 4 minutes between client and server. 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
And that's it, with these simple steps we have 2FA configured on the SSH server, and the TOPT will be required apart from your password next time you try to connect:
ssh facu@192.168.35.72 Password: Verification code:
With this Teratip we have shown how easy it is to implement 2FA and increase security towards our SSH servers without much effort.
Final thoughts
Incorporating an extra layer of security through 2FA with Google Authenticator into your SSH access is a pivotal step towards fortifying your cloud infrastructure. By following the systematic guide outlined in this blog post, you've empowered yourself to safeguard sensitive data and resources from unauthorized access. With enhanced authentication in place, you're well-equipped to confidently navigate the digital landscape, knowing that your cloud resources remain shielded from potential threats.
Facundo Montero
Cloud Engineer
Teracloud
If you want to know more about Security, we suggest checking Prevent (and save money in the process) Security Hub findings related to old ECR images scanned
If you are interested in learning more about our TeraTips or our blog's content, we invite you to see all the content entries that we have created for you and your needs.
