Google Authenticator: Securing SSH

Google Authenticator: Securing SSH

Typically, two methods are used for user authentication when accessing via SSH: by key and by password. Undoubtedly, key-based authentication is a significantly safer method, but this option is not always feasible. For example, if access occurs from a “foreign” computer where it’s difficult or unsafe to place the private key, one has to resort to standard password login.

Regardless of password complexity, there is always a risk of it being “leaked”. Experience shows that passwords can be compromised by attackers in several ways, the most common being a keylogger on the user’s computer or password interception via Trojans on the server side. This is precisely why it’s wise to implement an additional user verification method—by using TOTP.

TOTP is additional random one-time verification codes generated by a special algorithm. On the client side, these codes can be obtained through various means. A TOTP provider can send codes via SMS to the user’s mobile phone; there are token key fobs with small LCD displays, but the most widely accepted solution is generally the use of special apps for modern smartphones.

We will use one of the popular solutions—Google Authenticator. This universal product can be used not only for additional protection of SSH servers—it can also be enabled for use with Google products, WordPress, Facebook, Joomla, Dropbox, and many other products and services. The Google Authenticator app is available for iOS, Android, Windows Mobile.

Now, let’s install Google Authenticator on our mobile device and begin configuring our CentOS server. First, let’s enable the EPEL repository and ensure time synchronization is active:

wget http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
rpm -ivh epel-release-6-8.noarch.rpm
yum install ntp
chkconfig ntpd on
service ntpd start

Installation of Google Authenticator can then be done with a single command:

yum install google-authenticator

After installing, let’s run the utility to specify general settings and obtain initial data for setting up the token on the mobile device:

# google-authenticator
https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/root@my.server.net%3Fsecret%3D6JXXXXXXXXXXXTX
Your new secret key is: 6JXXXXXXXXXXXTX
Your verification code is XXXXX
Your emergency scratch codes are:
8XXXXXX5
4XXXXXX7
7XXXXXX3
2XXXXXX9
2XXXXXX0

Do you want me to update your "~/.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, tokens are good for 30 seconds and 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. If you experience problems with poor time synchronization, you can increase the window from its default size of 1:30min to about 4min. Do you want to do so (y/n) y

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
#

The easiest way to set up the mobile token is to load the QR code in the desktop browser at the specified link, then select “Add record” and “Scan barcode” in the smartphone app. After that, our smartphone will generate a unique code every 30 seconds, which will be necessary for access to the server.

Let’s proceed to configure the SSH server. At the very beginning of the PAM configuration file /etc/pam.d/sshd, we will include the corresponding module:

auth required pam_google_authenticator.so

Next, we will open our favorite text editor to edit the main SSH configuration file (/etc/ssh/sshd_config) and set the parameter:

ChallengeResponseAuthentication yes

After that, restart sshd:

service sshd restart

Configuration is now complete. Let’s try to connect from another computer and test it. Initially, the remote server will prompt for the verification code, which must be entered as a six-digit number obtained from the Google Authenticator app. Then, the server will prompt for the password, which will be specified to gain access to our server:

desktop# ssh root@185.14.XX.XX
Verification code:
Password:
server#

In the case of using key-based authentication, Google Authenticator will not require entering a verification code—extra verification is performed only when logging in with a password.

In conclusion, several recommendations:

• Whenever possible, use SSH key-based authentication.
• Use a separate password to protect the private key; do not store the key in an unencrypted form.
• The minimum password length should be 12-14 characters.
• The password should contain letters in different cases, numbers, and special characters.
• If possible, change the sshd port to a different, non-standard one.

Good luck and secure working!