Enable 2FA with SSH Connection

If you don’t know, I’m a big fan of two-factor authentication. I often talk about it integrated into your web applications access points, like wp-admin in WordPress and administrator in Joomla, but in this post I’m going to talk about leveraging it with your SSH connections.

When configuring your server access points it’s important you enable Public Key authentication in the place of passwords. Mainly because, unlike passwords, you can’t exactly brute force the access point with the keys enabled. There is also a functional aspect to it, not having to worry about passwords is great. Once you have it configured you can quickly access any of your boxes without having to remember or store the passwords. An example of where this would have been in your favor is the SSHD rootkit outbreak in February. With public keys enabled, those affected would have been spared compromises as passwords would not have been stolen.

Also, when possible I like to enable IP management that allows you to whitelist the IP’s you are coming in from, but unfortunately the latter is not always available, especially if your IP is dynamic. So to address this I like to enforce a second layer of authentication on the SSH entry point.

There are a number of mechanisms that will allow this, but the one that I have become most partial over the past few months is the integration points offered by Duo Security. What I am most fond of is the ability to manage my various access points within their system, meaning I can have all my 2FA’s configured for systems and web applications (i.e., personal blogs, websites, servers). Fortunately, the first 10 users are free, which is pretty awesome.

Fortunately, there are various options, one being using Google Authenticator PAM module, also described here, but I’m still partial for Duo Security’s configuration. Yes, you can configure Duo Security to work via PAM as well. You can also configure it to operate for specific user groups and users as required. I don’t have this last piece configured, but with the paid versions you have the options to configure your login controls. By login controls I mean the ability to define when to require it, say a network is not recognized or from a different range. That in itself can be pretty powerful. I also like the ability to apply this configuration globally to all my systems leveraging the Duo Security 2FA mechanisms.

A Few Configuration Points

For the most part, following these instructions won’t steer you wrong, but you might run into two issues. First is with having a compiler, second is with having openssl.

When you start, you’re going to want a compiler installed, gcc works fine.

# yum install gcc

Another note, if you run the install and you are confronted with something like the following, then you’re missing open-ssl, but openssl-devel, not the regular version:

checking for openssl/ssl.h in /usr/local/ssl... no
checking for openssl/ssl.h in /usr/lib/ssl... no
checking for openssl/ssl.h in /usr/ssl... no
checking for openssl/ssl.h in /usr/pkg... no
checking for openssl/ssl.h in /usr/local... no
checking for openssl/ssl.h in /usr... no
checking whether compiling and linking against OpenSSL works... no
configure: error: in `/home/tony/duo_unix-1.9.3':
configure: error: OpenSSL not found
See `config.log' for more details

What the documentation doesn’t tell you is what version of openssl you need, here it is:

# yum install openssl-devel

This is not the same as openssl-devel.i686 so be careful. This should get you past that error.


One thing I would recommend when configuring is to modify your integration point so that it performs an automated push to your phone, in the place of giving you an option. By default, when you first configure it’ll prompt the user with four options:

Enter a passcode or select one of the following options:

 1. Duo Push to XXX-XXX-1234
 2. Phone call to XXX-XXX-1234
 3. SMS passcodes to XXX-XXX-1234

To understand why that is bad I recommend reading the latest post by my friend Daniel on the insecurities of 2FA that depends on SMS and Phone Calls. While I am not 100% in tune with some of his opinions, specifically because of a users ability to harden their mobile device, he does bring up some interesting points. Because of that, if you disable the other options by default, it’ll do an automatic push to your mobile application, which works very differently than using SMS code.

To do this, you’ll want to add the auto push option so that the user is unable to set the various authentication mechanisms:

; Duo integration key
ikey = Integration Key
; Duo secret key
skey = Secret Key
; Duo API host
host = Host Address
; Send command for Duo Push authentication
;pushinfo = yes
autopush = yes

Layered Defense

What’s really important here is the ability to enable two factor authentication on your ssh connection. Whether you do it with Google Authenticator, WiKID, Duo Security or any of the other various options available, the key is to enable it. A layered defense is the most effective approach in today’s fight against cyber warfare, learn to embrace and implement it.


  1. Vid Luther on July 24, 2013 at 10:44 pm

    Good stuff, i’ll also suggest Authy (https://www.authy.com/products/ssh), very solid and friendly in our tests so far.

    Also faster to get implemented than duo-security by about 3-4 seconds :).

    • perezbox on July 25, 2013 at 12:22 am

      Oh, cool, haven’t heard of it, will have to try it on one of my servers, see how it goes.

Leave a Comment