Before installing and configuring the Google Authenticator on a virtual server you need to check and do a few few things to avoid getting locked out of the server. I have seen this grub configuration issue on virtual Ubuntu 18.04, 20.04, and 22.04 server installs on both HyperV and vSphere infrastructures. Also, make sure that you have multiple ssh terminals open prior to restarting sshd in the event the configuration is incorrect.
In the examples below I am only targeting admin accounts with sudo privileges – normal user accounts can log in without being prompted for a Google Authenticator code. Users logging in at the terminal will not be prompted for the authentication code. This configuration only affects ssh logins.
Grub Recovery Issue:
Prior to google authenticator setup you should check to make sure that the grub bootup menu is displayed long enough for you to capture it in the event that you need to do an emergency recovery. Doom on you if you don’t change this behavior in the grub configuration.
vim /etc/default/grub GRUB_DEFAULT=0 #GRUB_TIMEOUT_STYLE=hidden GRUB_TIMEOUT=20
update-grub
Reboot and verify the grub screen appears in the terminal window for a suitable amount of time.
Google Authenticator Install and Configuration – as root:
As a security suggestion – open multiple ssh sessions to avoid possible lockout during configuration.
A second suggestion – Users should not be added to the group (i.e. sudo) until after doing the user authenticator setup if they will be doing the setup using SSH. User setup of the authenticator from the local terminal will not matter since this configuration only affects ssh logins.
Check for users in certain group, in this case “sudo”:
getent group sudo
Install Gooogle Authenticator:
apt-get install libpam-google-authenticator
Edit and add to the bottom of the file (the order of these two lines matters):
vim /etc/pam.d/sshd # Google authenticator - only for users in sudo group auth [success=done default=ignore] pam_succeed_if.so user notingroup sudo # Google authenticator - prompt for code auth required pam_google_authenticator.so
Edit the sshd config file:
vim /etc/ssh/sshd_config # For google authenticator # Enable challenge-response passwords ChallengeResponseAuthentication yes
Restart ssh daemon:
systemctl restart sshd
Client Setup – As normal user:
As a normal user in the terminal:
google-authenticator
Answer the following questions:
Do you want authentication tokens to be time-based (y/n) y
In the phone app, add key or use QR code. Then enter the code from the app:
Enter code from app (-1 to skip): <code>
Copy emergency one-time use codes to a safe file.
Do you want me to update your "/home/shawn/.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
At this point you are done. Remember to add/re-add users back to the sudo group if you removed them.