You can disable password authentication for SSH logins while keeping Google Authenticator enabled by modifying the
/etc/ssh/sshd_config file on your Linux server. This configuration forces users to authenticate using a time-based one-time password (TOTP) instead of traditional passwords, significantly enhancing security against brute-force attacks and credential stuffing attempts.
Prerequisites and Installation
Before altering authentication methods, ensure that the Google Authenticator PAM module is installed and functional on your system. Most modern Linux distributions provide this package in their default repositories. For Debian-based systems like Ubuntu, you can install it using
sudo apt-get install libpam-google-authenticator. On Red Hat-based systems such as CentOS or Fedora, use
sudo yum install google-authenticator or
dnf.
Once installed, each user who needs to use two-factor authentication must run the
google-authenticator command. This interactive tool generates a QR code that the user scans with their mobile authenticator app (such as Google Authenticator, Authy, or Microsoft Authenticator). It also provides emergency scratch codes which should be saved securely in case the user loses access to their phone. Without this initial setup, disabling password authentication will lock users out immediately because they will have no valid second factor configured.
Configuring SSH Daemon Settings
The core of this configuration lies in editing the SSH daemon configuration file located at
/etc/ssh/sshd_config. You must open this file with root privileges using a text editor like
nano or
vim. Look for the line that specifies
ChallengeResponseAuthentication or
UsePAM. In many modern configurations, especially those using systemd,
UsePAM yes is already present and required for PAM modules to function correctly.
You need to set
ChallengeResponseAuthentication no if it is not already commented out, but more importantly, you must ensure that
PasswordAuthentication no is explicitly defined. This directive tells the SSH server to reject any login attempts that rely solely on a username and password combination. If you are using key-based authentication alongside Google Authenticator, you might also want to keep
PubkeyAuthentication yes enabled, allowing users to log in with keys first and then provide the TOTP code, or you can force TOTP-only access depending on your security policy.
After making these changes, save the file. It is critical to test the configuration syntax before restarting the service to avoid locking yourself out. Run
sudo sshd -t to check for errors. If the output is empty, the configuration is syntactically correct. If errors appear, correct them before proceeding.
Integrating Google Authenticator with PAM
To make the SSH daemon recognize the Google Authenticator module, you must edit the PAM configuration for SSH. Locate the file
/etc/pam.d/sshd on most distributions. Add the following line to the end of the file:
auth required pam_google_authenticator.so. This line instructs the Pluggable Authentication Modules system to require a valid TOTP code for every SSH login attempt.
Depending on your specific Linux distribution and version, you may also need to modify the
/etc/ssh/sshd_config to include
AuthenticationMethods keyboard-interactive,pubkey or similar directives if you are combining multiple methods. However, for pure password-to-TOTP replacement, ensuring
PasswordAuthentication no and adding the PAM line is usually sufficient. The
keyboard-interactive method is often used in conjunction with PAM to handle the prompt for the verification code.
Restart the SSH service to apply the changes. Use
sudo systemctl restart sshd on systemd-based systems. Before disconnecting your current session, verify that you can still log in with the new configuration from a different terminal or device. This step prevents accidental lockouts due to misconfiguration.
Security Considerations and Best Practices
Disabling password authentication reduces the attack surface significantly, as attackers cannot guess passwords. However, you must ensure that all users have properly configured their Google Authenticator apps. Provide clear documentation on how to scan the QR code and store emergency codes. Additionally, consider implementing IP whitelisting for administrative accounts if possible, adding another layer of defense.
For environments requiring high availability, monitor the SSH logs closely after implementation. Logs in
/var/log/auth.log or
/var/log/secure will show successful authentications and failures. If you notice unexpected denials, it may indicate that the PAM module is not loading correctly or that users have not completed the initial setup. Regularly update the
libpam-google-authenticator package to benefit from security patches.
Avoiding Google Authenticator Re-Authentication in Existing SSH Sessions on EC2 discusses how to manage session persistence, which complements this hardening strategy by reducing friction for legitimate users after the initial login.
Frequently Asked Questions
What happens if I lose my phone?
You can use the emergency scratch codes generated during the initial
google-authenticator setup to log in. These codes are single-use and should be stored securely offline. If you lose both your phone and the scratch codes, you will need physical or console access to the server to reset the Google Authenticator configuration for your user account.
Can I use key-based authentication with Google Authenticator?
Yes, you can combine public key authentication with Google Authenticator. By setting
AuthenticationMethods publickey,keyboard-interactive in
sshd_config, users must first provide their SSH key and then enter the TOTP code. This two-step process offers robust security while maintaining convenience for users who manage their keys securely.
How do I troubleshoot if I get locked out?
If you are locked out, access the server via a console interface such as AWS EC2 Instance Connect, DigitalOcean Rescue Mode, or physical console access. Once logged in, temporarily comment out the
auth required pam_google_authenticator.so line in
/etc/pam.d/sshd and set
PasswordAuthentication yes in
/etc/ssh/sshd_config. Restart the SSH service to regain access, then reconfigure the settings carefully.
Does this work on all Linux distributions?
This method works on most major Linux distributions including Ubuntu, Debian, CentOS, RHEL, and Fedora, as they all support PAM and OpenSSH. Minor variations may exist in the location of configuration files or package names, but the underlying mechanism remains consistent. Always consult your distribution's documentation for specific paths if the standard locations differ.
Is Google Authenticator secure enough for production?
Google Authenticator uses Time-based One-Time Passwords (TOTP), which is an industry-standard method for two-factor authentication. When combined with strong SSH keys or complex passwords, it provides a high level of security. However, security also depends on proper implementation, such as protecting the private keys and ensuring the server itself is hardened against other vectors of attack.