[corin_]

As noted alsewhere, ForceCommand is a nicer option, and can be done with something like this in sshd_config:

  Match group yubikey
  #       ForceCommand /usr/local/bin/yubikey.sh
         ForceCommand /usr/local/bin/mobileverification.sh

The commented out script is something I wrote to authenticate Yubikeys - see http://yubico.com/yubikey

And the mobileverification.sh sends a randomly generated 4 digit pin code to the phone number that user has saved in ~/.ssh/mobile_number and asks them to enter it.

Edit: in case anyone is interested, mobileverification.sh at http://pastie.org/pastes/2579517/text?key=tv1xciwdubnwi165fz... and yubikey.sh at http://pastie.org/pastes/2579528/text?key=krpmwrivbvrjmx0xb3...

Edit2: It's worth pointing out that both those scripts were written fairly quickly by me, for basic personal use. If you want to use them I would recommend going through them and making sure I didn't screw anything up.

[zobzu]

These are much more sensible that the OP's solution.

Just to be clear to anyone reading, because it's not really explained:

* OP double-protects the SSH key. It means you need the key's passphrase and another factor (Google authenticator) to decrypt the ssh key. Then the ssh key is used to auth with the server.

=> the authentication with the server is still one factor auth, compromising the key at any level still grants access.

=> obligatory analogy: OP did like that: put your car key in a box that also has a key. Attacker just need a copy of the key in the box to open the door (granted that he won't use any physical attack on the door :p)

=> 2 (or more) factor authentication should always be used on the component that does the final authentication.

* People using ForceCommand apply the 2 factor at the last step of authentication, that is, once the ssh key authenticated you correctly, you still need to authenticate to something else before being given access.

=> obligatory analogy: now you have a key and a cellphone. you turn the key in the car and the door doesn't fully unlock. you gotta enter a code given by the cellphone before it actually opens. if the attacker get a copy of your key, it's not enough. if the attacker gets a copy of your phone's passcode (even thus it changes each time), its not enough.

[mdp]

"* OP double-protects the SSH key. It means you need the key's passphrase and another factor (Google authenticator) to decrypt the ssh key. Then the ssh key is used to auth with the server. => the authentication with the server is still one factor auth, compromising the key at any level still grants access."

This is not correct. You can't decrypt a key with a one time password.

The OP is requiring a the second factor(the OTP) after the key is sent to the server and authenticated.

[moomerman]

The method listed in the article does authenticate with the SSH key first and then the second factor kicks in only if the key (and passphrase) are valid.

Doesn't ForceCommand do exactly the same thing except it allows you to do it globally?

[simcop2387]

Not only does it allow you to do it globally, it doesn't allow a user to log in and disable it on you either. If you have to have them turn it on in ~/.ssh/authorized_keys all it takes is someone to get in once to add in a key that doesn't require that any more.

[helper]

We use duosecurity.com to do essentially the same thing. It supports text messaging and also has iPhone and Android apps. And its free upto 10 users.

[jaryd]

Thanks for the post! I just modded this to work with twilio -- sweet!

Additionally, if you don't want to pay for SMS you could send an email to your cell number.

[mentat]

What needs to go into trusted_keys?

[corin_]

Yeah, it is 12. Here is a basic usage guide:

  # groupadd yubikey
  # usermod -G yubikey USERNAME
  # echo "yubikeyid" >> /home/USERNAME/.ssh/trusted_yubikeys
  # (yubikeyid is first 12 characters of the OTP)
  # chmod 755 /usr/local/bin/yubikey.sh
  # (this file is /usr/local/bin/yubikey.sh)
  # echo "Match group yubikey" >> /etc/ssh/sshd_config
  # echo "  ForceCommand /usr/local/bin/yubikey.sh" >> /etc/ssh/sshd_config
  # (that's a tab before ForceCommand)
  # /etc/init.d/ssh restart

[jaryd]

If you're still on CentOS 5.7 you might need to upgrade your openssh package. Might I recommend openssh-5.8.p1 with the HPN patch (http://www.psc.edu/networking/projects/hpn-ssh/#patches)

[corin_]

Was I ever on CentOS 5.7?

[mentat]

Thank you!

[corin_]

~/.ssh/trusted_yubikeys ?

It's the I'd of your specific Yubikey - I'm on my phone on a train right now, but off the top of my head it is the first 12 characters that get printed when you use your Yubikey. Pretty sure it's 12, anyway.

[moomerman]

Cool examples - thanks.