30

I currently have a Ubuntu Server 12.04 running OpenSSH along with Samba and a few other services. At the current time I have public key authentication set up, and I'm wondering if it's possible to set up two factor authentication? I've been looking at Google Authenticator which I currently use with my Gmail account.

I've found a PAM module that looks like it will be compatible however it seems that you are forced to use a password and the code generated.

I'm wondering if there is a way to use the Google Authenticator Application (or something similar) along with my public key to authenticate into my SSH server?

Mark Henderson
  • 68,316
  • 31
  • 175
  • 255
Concrete Donkey
  • 435
  • 5
  • 8
  • Most of the comments seem to be bug reports mentioning that it's impossible to use PAM and public key authentication with OpenSSH. I've also found parts mentioning it's redundant as I'm using a pass phrase with my key. With all of the solutions seemingly only allowing Google Authenticator and a password not a public key. I could be missing it completely, but I just don't see how to implement both. – Concrete Donkey Jul 20 '12 at 03:38
  • Not sure why this has a -1, this is a very interesting question and I too would like to know the answer (not that I'm likely to use it, but even so, good to stash in the knowledge banks) – Mark Henderson Jul 20 '12 at 03:45
  • @Pierre Are you trying to require **both** public key authentication, and a Google OTP? – mgorven Jul 20 '12 at 04:24
  • @mgorven Yes, I was trying to set up both public key and Google OTP. I've heard some people say it's sufficient as having a passphrase on the key counts as two factor but I'm concerned about malware stealing the unencrypted key from memory. I'd rather have two completely separate devices used for authentication, I am slightly paranoid. – Concrete Donkey Jul 20 '12 at 20:03
  • This is intended to become officially implemented in 6.2: https://bugzilla.mindrot.org/show_bug.cgi?id=983#c59 – Tobias Kienzler Feb 08 '13 at 17:20

7 Answers7

8

Red Hat have added a patch to OpenSSH in RHEL (and therefore CentOS) 6.3 to require multiple authentication mechanisms, so you can do something like this:

RequiredAuthentications2 publickey,keyboard-interactive

See the release notes for not much more detail.

Unfortunately this feature doesn't seem to be in OpenSSH upstream nor Ubuntu 12.04, so unless you want to find the patch and recompile OpenSSH I'm afraid you're out of luck.

mgorven
  • 30,036
  • 7
  • 76
  • 121
  • I have to say I appreciate the effort you put into finding me an answer, I certainly tried going over a few pages of Google results but all implied what you mentioned I had to use a password and a OTP only. I will probably create a CentOS VM to play around with the feature. – Concrete Donkey Jul 20 '12 at 23:02
  • @Pierre Not *that* much effort, I knew about this feature before ;-) – mgorven Jul 20 '12 at 23:13
  • I've found the [corresponding bug](https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=657378) and [some further notes](http://rhn.redhat.com/errata/RHSA-2012-0884.html). The bug includes the patch as an attachment. – Robie Basak Jan 18 '13 at 19:15
  • And here's an [upstream openssh bug](https://bugzilla.mindrot.org/show_bug.cgi?id=983). It looks like similiar functionality will be upstream in openssh soon. – Robie Basak Jan 18 '13 at 19:20
  • openssh 6.2 has landed in the development release of Ubuntu, so save for any disasters this support will be in the expected 13.10 release. It uses upstream's `AuthenticationMethods` to specify multiple required methods, so that you can require both an ssh key and PAM, with PAM doing the Google Authenticator end. – Robie Basak Jul 31 '13 at 09:39
8

You are looking for Duo Security

Ajith
  • 181
  • 2
  • 1
    This. Yes. I love this thing! – LVLAaron Jul 26 '12 at 23:15
  • Definitely - Duo is easy to set up for Unix/Linux (link in answer), OpenVPN (https://www.duosecurity.com/docs/openvpn_as), or any OATH TOTP based two-factor service, or LastPass password management. Any service that's compatible with Google Authenticator (which uses TOTP) can be used with Duo's mobile app, or a hardware token supporting TOTP. – RichVel Aug 23 '14 at 07:15
5

You can use both the Google Authenticator PAM module and public keys, but only one at the time will be used for a given authentication. That is, if a user logs in with an authorized public key, no token will be required.

Or, to say it otherwise: tokens are only required for password authentications, not SSH keys.

This limitation does not come from the Google Authenticator module by the way, but from SSH, which only implements two factor authentication (via ChallengeResponseAuthentication) for PAM, but doesn't call PAM when a valid public key is provided.

raphink
  • 11,337
  • 6
  • 36
  • 47
  • This was correct, but has now changed. openssh 6.2 adds an `AuthenticationMethods` configuration paramaeter that can flip this. Now you can require both. – Robie Basak Jul 31 '13 at 09:41
3

This question is from 2012. Since, SSH has changed and the SSH2 protocol has been implemented.

On more recent versions of SSH ( >= 6.2), man sshd_config mentions:

AuthenticationMethods
       Specifies the authentication methods that must be successfully completed for a user to be
       granted access.  This option must be followed by one or more comma-separated lists of
       authentication method names.  Successful authentication requires completion of every method
       in at least one of these lists.

       For example, an argument of ``publickey,password publickey,keyboard-interactive'' would
       require the user to complete public key authentication, followed by either password or key-
       board interactive authentication.  Only methods that are next in one or more lists are
       offered at each stage, so for this example, it would not be possible to attempt password or
       keyboard-interactive authentication before public key.

       This option is only available for SSH protocol 2 and will yield a fatal error if enabled if
       protocol 1 is also enabled.  Note that each authentication method listed should also be
       explicitly enabled in the configuration.  The default is not to require multiple authentica-
       tion; successful completion of a single authentication method is sufficient.

This page http://lwn.net/Articles/544640/ also mentions the possibility of using a publickey and a PAM authentication at the same time.

liquidity
  • 408
  • 1
  • 7
  • 22
2

I know this question is a little stale, but for the sake of future people (myself included) who are looking for a solution, there's also talk of using the ForceCommand option in the sshd_config file to run a script which then performs the authentication. There's an example script here you can modify a bit to your needs, although in that example he calls it from the authorized_keys file instead of making it system-wide with sshd_config's ForceCommand.

Amazingant
  • 175
  • 5
1

Get a YubiKey and follow this guide http://berrange.com/posts/2011/12/18/multi-factor-ssh-authentication-using-yubikey-and-ssh-public-keys-together/

AFAIK, this is the best to way to implement Yubikey on your server for SSH access. The above guide enables you go use public-key + yubikey whereas if you go with the official guide (http://code.google.com/p/yubico-pam/wiki/YubikeyAndSSHViaPAM), it doesn't work with public-key.

Regards, Vip

vagarwal
  • 845
  • 6
  • 8
0

If you set a passphrase on your private key then you have two-factor authentication already. In order to log in people would need:

  1. something you have - your private key
  2. something you know - the passphrase to your private key
Bart B
  • 3,419
  • 6
  • 30
  • 42
  • 3
    Two passwords do **not** make two-factor authentication. The key itself is not a valid "something you have" because it's not a thing, just a piece of information. The thing must be non-copiable, or at least non-trivially copiable, to be any use as an authentication factor. – MadHatter Jul 20 '12 at 15:41
  • 2
    I disagree entirely. If keys and certificates are not "something you have" then what are they? They are definitely not "something you know" (are you in the habit of learning off your SSH key?), and absolutely not "something you are". Those are the only three choices, so by a process of elimination, they most certainly are "something you have". – Bart B Jul 23 '12 at 13:20
  • 1
    I agree; for me, the problem is in the maxim (something you have|know|are). The idea of two-factor authentication is to require members of two classes with different properties; something you know is easy to carry, but it can be known by someone else as the same time as you know it; so we add a second, different factor. The "something you have" is only different if it's uncopiable (or hard to copy). Otherwise, sure, it's not something you know, but **it's not qualitatively different from something you know**, because someone else can have it at the same time as you. – MadHatter Jul 23 '12 at 13:34
  • A private SSH key should be hard to copy in the same way that an RSA token should be hard to steal. You can only steal someone's token if you are in the same place as that token. Similarly, the only way you should be able to get a private key is if you are on their computer. If the attacker is on your computer, you've got bigger problems than your SSH keys being compromised! Random guy on the internet attacking your server can not (easily) get your SSH private key, just like they can't get your RSA token. – Bart B Jul 24 '12 at 11:59
  • 1
    I hear you, but a fundamental difference is that when the RSA token's been stolen, you know it's gone, as you haven't got it any more; then you contact your security department, and they freeze out that device. When the key's been stolen, you've still got it - so that safeguard, peculiar to hard-to-copy physical objects, is gone. – MadHatter Jul 24 '12 at 12:05
  • I'll grant you that RSA tokens are a stronger second factor because you know when one is missing. However, I think we can also both agree that a password protected key pair does count as two-factor, and it does present a significant improvement in security over either just a password or just a key with a blank password. – Bart B Jul 24 '12 at 15:35
  • 2
    I definitely agree that a password-protected keypair is a big improvement in security over straight username+password. I don't, sadly, agree that such a pair counts as two-factor, and we'll probably have to agree to disagree on that. – MadHatter Jul 25 '12 at 07:28
  • @BartB the problem with SSH keys + Key Passphrase as "2 factors" is if someone has a crap password (`12345`) and an attacker gets a copy of the key the security is blown (and worse, as MadHatter pointed out you might not know it's blown). How easy is it to get some private keys? Google `private key site:pastebin.com` and weep for humanity. *physical* tokens that must be *physically* (and obviously) stolen are pretty much de rigueur for two-factor authentication. You'd notice losing your phone (or your thumb, which is a big plus for biometrics!) – voretaq7 Sep 08 '12 at 02:24
  • I'm agreeing with @BartB here, but I think another central issue is that most two factor author devices are also physical. So in essence that is still somewhat better and different to the SSH keypair that you 'physically own'. – atx Dec 25 '12 at 11:14
  • 3
    If you have a passphrase-encrypted private key, you only prove one thing to the server: that your client knows the private key. It doesn't prove to the server that you know your passphrase; the server doesn't even know about the existence of your passphrase. Therefore it is only "something you know" (since your client knows it) and only one factor. If an attacker gets hold of just one thing (your private key) then you are compromised. That's one factor. Arguing that your passphrase and private key count as two factors is just an exercise in sophistry. What counts is what happens on the wire. – Robie Basak Jan 18 '13 at 18:34