Author Archives: Toledo12

Secure SSH with Google Authenticator Two-Factor Authentication on CentOS 7

SSH access is always critical and you might want to find ways to improve the security of your SSH access.

In this article we will see how we can secure SSH with simple two factor authentication by using Google Authenticator. Before using it you have to integrate the SSH daemon on your server with Google Authenticator one time password protocol TOTP and another restriction is that you must have your android phone with you all the time or at least the time you want SSH access

First of all we will install the open source Google Authenticator PAM module by executing the following command on the shell.

yum install google-authenticator

The next step is to get the verification code. It’s a very simple command to get the verification code and scratch codes by just answering simple questions of server which he will ask you.

google-authenticator

Do you want authentication tokens to be time-based (y/n) y

You will get an output like the following screenshot which is being displayed to help you step by step as this step is very important and crucial.

Write down the emergency scratch codes somewhere safe, they can only be used one time each, and they’re intended for use if you lose your phone.

Do you want me to update your "/root/.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) 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

Now download Google authenticator application – or much better Authy – on your Mobile phone, the app exists for Android and Iphone. Well I have Android so I will download it from Google Play Store where I searched it out just by typing « google authenticator » or « Authy ». « Authy » is able to backup your accounts in their Cloud in case you loose your phone…

Scan the code above with your authenticator. The Account Name should be named like root@www.ordi.ch

The next step is to change some files which we will start by first changing /etc/pam.d/sshd.

nano /etc/pam.d/sshd

Add the following line to the bottom of line:

auth required pam_google_authenticator.so 

–> Save the file

Change the next file which is /etc/ssh/sshd_config.

nano /etc/ssh/sshd_config

Add the following line in the file and if its already placed then change the parameter to « yes »:

ChallengeResponseAuthentication yes 

–> Save the file

Now restart the service of ssh by the following command:

service sshd restart

Last step is to test the service by connecting with SSH to the server to see if it will require verification code. You can see the following screenshot which shows the verification code that keeps on changing time after time and you have to login with it: