[HowTo] Secure Your VestaCP Centos 7 VPS with Two-factor Google Authenticator

[xorro]

Install the Google-Authenticator

Google-Authenticator app is available on all of the mobile phones, you can download the Android app from Google Play and the IOS app (iPhone users) from the App Store.

Installing Google’s PAM

PAM (Pluggable Authentication Module) is authentication infrastructure based on Linux system to authenticate a user.

First of all install EPEL repository with the following command:

Code: Select all

yum install epel-release

Now install the Google’s PAM:

Code: Select all

yum install google-authenticator

Configuring Google’s PAM

After the installation process is finished, you can run the script which helps you generate a key for the user you want to add a second factor for, this key is generated on a user-based system not system-wide, this means every user that wants to use an OTP auth will need to log in and run the generator script to get their own key.

Execute the following command to run the initialization script:

Code: Select all

google-authenticator

After you run the command, you’ll be asked a few questions. The first one asks if authentication tokens should be time-based. it’s recommended to answer with “Y”.

After that, a huge QR code will appear on your terminal which you have to scan it with your Phone so the profile automatically adds to your Google-Authenticator app.

And also make sure to write down the “secret key”, “verification code”, and “emergency scratch codes” So if you lost your phone or accidentally remove the Application from it you will be able to log in to your server.

Now you will be prompt for some questions which inform PAM how to function, go ahead and answer them with “Y” or “N” and it’s pretty easy to choose whats best for you.

Configuring SSH

After you answered all the questions, your Google’s PAM is ready and configured. now we just have to do some configuration for our SSH.

Open up the SSH configuration file with the following command:

Code: Select all

nano /etc/pam.d/sshd

Add the following line at the very end of the file:

Code: Select all

auth required pam_google_authenticator.so nullok

Now we will configure SSH to support this kind of authentication, Open the “sshd_config” file with the command below:

Code: Select all

nano /etc/ssh/sshd_config

Look for the line that refers to “ChallengeResponseAuthentication” and set its value to “yes”. like below:

Code: Select all

ChallengeResponseAuthentication yes

Restart your SSH service and you are good to go:

Code: Select all

systemctl restart sshd

From now on you will be asked for a “Verification-code”, which you have to get if from your Google-Authenticator app form your phone.

[adamjedgar]

Has anyone tried this recently?

I just followed this through and I am not asked for Google Authentication (login in using either root or admin users)

Does it only apply to normal users?

[grayfolk]

Has anyone tried this recently?

I just followed this through and I am not asked for Google Authentication (login in using either root or admin users)

Does it only apply to normal users?

This is applyed for SSH users only, not for login into Vesta CP via web interface.

[adamjedgar]

Oh ok. No worries thanks for that.

Perhaps this could be a feature request for future versions as other control panels have this for the admin interface (ie Virtualmin uses it).

[servtelecom]

It would be nice if it were applied to all services, that is to say that it would serve so that exim, dovecot and ssh, when having this option activated they have to force the device to be registered in order to be used.
Lately they are getting to guess the mail passwords and by many filters they put they do it equally, with this double validation, if the device is not in a server database, it could not use them.

More suggestions would be a greater control of fail2ban and also a greater control of exim to edit the files spam-block.conf white-list.conf to be able to block or let pass with more comfort of configuration

[samolsen]

It would be nice if it were applied to all services, that is to say that it would serve so that exim, dovecot and ssh, when having this option activated they have to force the device to be registered in order to be used.
Lately they are getting to guess the mail passwords and by many geometry dash filters they put they do it equally, with this double validation, if the device is not in a server database, it could not use them.

More suggestions would be a greater control of fail2ban and also a greater control of exim to edit the files spam-block.conf white-list.conf to be able to block or let pass with more comfort of configuration

I also think the same way. This is applied for SSH users only...