Type your search keyword, and press enter

Hardening SSH with OTP for 2 factor authentication

Your ads will be inserted here by

Easy Plugin for AdSense.

Please go to the plugin admin page to
Paste your ad code OR
Suppress this ad slot.

Something I’ve been meaning to do for a while is look into the possibility of using 2 factor authentication, or 2FA, with SSH connections. This would add a much needed level of security to servers I host out in the wild.

Here’s how I did it:

The Google Authenticator mobile app used to be an open source project, it isn’t any more but the project has been kindly forked and looked after by Red Hat under the guise of the FreeOTP project. The first step is to download the app, which is available for Android and iOS there is even a Pebble project in the works. https://fedorahosted.org/freeotp/

Google Play: https://play.google.com/store/apps/details?id=org.fedorahosted.freeotp

iTunes: https://itunes.apple.com/us/app/freeotp/id872559395

Next we need to configure PAM, this is the component in Linux which ties authentication together. It allows us to add modules for various authentication sources into various applications which require authentication, in this case we need a module compatible with FreeOTP to provide authentication to SSH.

We’ll be using the pam_oath for this, the OATH toolkit is designed for building one-time password based systems. http://www.nongnu.org/oath-toolkit/

yum install pam_oath oathtool gen-oath-safe

This gives us the tools needed to link in to pam, and also generate the initial keys to share between the devices.

Next we need to edit /etc/pam.d/ssh to recognise this module by adding the following line to the top:

auth sufficient pam_oath.so usersfile=/etc/liboath/users.oath window=10 digits=6

Notice we specify a users file, this is where the users who harness OTP will have their details stored. Once this is saved we need to restart sshd

service sshd restart


systemctl restart sshd

Your ads will be inserted here by

Easy Plugin for AdSense.

Please go to the plugin admin page to
Paste your ad code OR
Suppress this ad slot.

So thats ssh configured, from now on when a user logs into the system via ssh, they will be prompted for a One-time password.

Next up we need to generate the keys which are to be shared between the target host (SSH) and the client generating the OTP (Android or iOS app)

gen-oath-safe jon hotp

Replacing jon with your username. hotp denotes the type of key to be generated, hotp being a counter based key and totp being a time based – choice is yours here.

This command will generate a number of codes, HEX, b32, QR and yubikey. The keys we are interested in are the HEX and the QR:


From the app select the QR scanning option on the top tool bar:


Scan the generated QR code which will then store the key in the application.

The final step is to add the HEX code to the file we referenced earlier in the sshd pam config file. Drop the following line /etc/liboath/users.oath (making sure you use your generated key and username):

HOTP jon -  da50cc2e1ee6726c847c5b960a62751e9bbea3a9

Once that file is saved we can go ahead and login via ssh with the specified user. You will now be prompted for a One-time password which can be generated by pressing on the entry within FreeOTP.

Note: if ssh keys are setup then these will be preferred over OTP, i’m sure a modification of the pam config would allow for both but haven’t spent any more time on this yet.




Etckeeper – config version control

A valuable tool I have been using for many years is etckeeper, it works by essentially turning your /etc directory into a git repository.

This is a fantasticly useful set of tools as any configuration changes can be logged and also reverted quite easily. Install and setup is exeptionally easy too!

Packages are available for most distributions, but my scenario (Fedora,CentOS,RHEL) was:

yum install etckeeper

Once the package was installed an initialisation must be performed:

etckeeper init

This essentially runs a “git init” in the /etc directory setting up the directory ready.

That’s all there is to the installation.

Using it is a matter of committing changes when they are made, my workflow generally consists of running a check to see if all previous changes were committed, make the change, commit the change.

etckeeper unclean

Will check the /etc directory for uncommitted changes, if they exist they can be committed in the same way as any new changes:

etckeeper commit

Running this command will present the familiar commit log screen in your favourite editor as it is essentially running a git commit from within the etc directory. Once the commit log is saved any changes are then stored within the version control system. A cron job is also in place to ensure a daily commit takes place, incase commits have been missed.

Now this is cool and extremely useful, but extending the git elements to push to a remote repository gives your etc that extra bit of resilience. Hook scripts are already present within /etc/etckeeper/commit.d/99push to recognise if a remote repository is configured and push to it on commit. Adding a remote repository is fairly simple, in my case I push to a gitlab (think self hosted github) server which I run.

First up a repository needs to be created in which to push to, I won’t go into detail here as there are hundreds if not thousands of Git tutorials out there. Gitlab has a repository created for each server and the ssh public key of each server stored to enable access.

cd /etc
git remote add origin git@gitlab01:etckeeper/server01.git
git push -u origin master

Will set the remote repository and populate it.

The last element to configure is the etckeeper config file, changing




(or whatever branch you choose to use)
And thats it! You an amazingly simple piece of software which could potentially save your Apache server, your Dovecot server or maybe even your job!