Google Authenticator provides 2-factor authentication (2FA), which can enhance the security of SSH logins.
Install Google Authenticator on the server
Generate the secret key and QR code
In this section, we will generate a secret key and a QR code for Google Authenticator.
Run the Google Authenticator PAM module
During the google-authenticator
command, you will be asked a series of questions:
- Generate a new secret key? -
Y
- Do you want me to update your
/home/user/.google_authenticator
file? -Y
- Do you want to disallow multiple uses of the same authentication token? -
Y
- By default, a new token is generated every 30 seconds. Do you want to change the time step size? -
N
- Do you want to enable rate-limiting? -
Y
For scripting purposes, use the following command with the specified options
This command executes the following functions:
-t
to generate a new secret key for time-based authentication-f
to overwrite any existing secret key-d
to provide the secret key and a URL that generates a QR code-w 3
to set a limit of 3 time skew windows-e 10
to set 10 emergency scratch codes-r 3 -R 30
to limit the rate of new tokens to 3 every 30s
The QR code can be scanned with a standard authenticator app on your smartphone, such as Bitwarden, Google Authenticator, or Proton Pass. Alternatively, you can manually enter the provided secret key.
Edit the PAM configuration for SSH on the server
Now, let’s modify the PAM configuration for SSH on the server.
Open the PAM configuration for SSH
At the bottom of the file, add the following lines
# Google Authenticator 2FA configuration
auth required pam_google_authenticator.so nullok
auth required pam_permit.so
The nullok
option in the line auth required pam_google_authenticator.so nullok
allows users, who have not yet configured Google Authenticator, to log in using their SSH keys. This feature can assist in the transition to 2FA. If this option is not required, feel free to remove it.
If you wish to necessitate password authentication in addition to the 2FA, insert the following line before the previously mentioned lines:
The order will determine how the user is prompted for authentication. To be extra clear, the following line will prompt the user in this order: 1) password; 2) 2FA code.
Control Flags in PAM
In the PAM (Pluggable Authentication Modules) configuration, control flags like required
and requisite
are used to determine how the system reacts to the success or failure of a module:
required: If a module flagged as
required
fails, the system will continue processing the rest of the modules before failing the authentication. This avoids revealing exactly which part of the process failed to potential attackers.requisite: If a
requisite
flagged module fails, the authentication process fails immediately. The system won’t continue to process the other modules. This gives instant failure feedback, but may also reveal more information to potential attackers about what part of the authentication process failed.
The choice between required
and requisite
depends on your specific security needs and strategy.
At the beginning of the file, you should comment out the following line
Update SSHD configuration
Edit the SSHD configuration file
Ensure that the following lines are present and not commented out
At the bottom of the file, add one of the following lines based on the desired behavior
- To require both an SSH key and either a password or the 2FA code:
- To require both an SSH key and the 2FA code:
If you want it, don’t forget to enable public key authentication:
Restart the SSHD service
Disabling 2FA
If you wish to disable 2FA, you can either remove or comment out the associated lines in /etc/pam.d/sshd
and /etc/ssh/sshd_config
. Following this, remember to restart the SSHD service.