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.

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.

"* 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.

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?

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.

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.

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.

What needs to go into trusted_keys?

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

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)

Was I ever on CentOS 5.7?

Thank you!

~/.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.

Cool examples - thanks.

If you're running a recent version of OpenSSH, you can add the 'ForceCommand' param to sshd_config to add it for all users. The only downside to this is it is for all users, so if you run something that needs to use key based login without the two factor method you'll need to validate that yourself within the script.

> The only downside to this is it is for all users

Look up the Match command, you can limit ForceCommand and many others to a specific "User, Group, Host and Address."

it seems to me that you're doing 2 factor on the ssh key decryption. That's not so useful IMO from the security point of view. The factor should be an alternative to the ssh key itself aka server side aka via ForceCommand as suggested

Cool, I wasn't aware of that option. Thanks!

GRC's Perfect Paper Passwords works well for me (https://www.grc.com/ppp.htm). It's similar to Last Pass's Grid authentication but less obnoxious IMO. One member of the GRC newsgroups has written a PAM which has served all of my 2FA needs (http://code.google.com/p/ppp-pam/).

A while back I wondered how hard it would be to integrate two-factor authentication on a web site using Google's Authenticator app, since it uses open protocols and is available on all platforms. Turns out it's incredibly easy. Even made a demo: http://dendory.net/twofactors/

This is cool. I'd also like to point out the PAM module: http://code.google.com/p/google-authenticator/source/browse/...

I was using the command="" stuff to restrict a user to only running rsync the other day and was considering writing the script in ruby as was done here. Does anyone have any opinion on how safe that is? The client shouldn't have that many ways to interact with the ruby process but I was still wondering if I should stick to something smaller like /bin/sh (not even bash) for safety.

if you exec the shell on your own (and make auth decisions on your own) outside of PAM you are basically destroying meaningful logging of successful/unsuccessful authentication, right?

You can log the events yourself. If it's a shell script, it would be as easy as:

    logger -p authpriv.notice "Some message about authentication"

That is great thank you, I was looking for something along those lines

Could a user bypass this by using: ssh user@host.com -Tv 'bash' ?

The command you pass in is available to the command="" script in SSH_ORIGINAL_COMMAND, so you can exec() that or ignore it

Just tried it and it still prompts for the auth code

Thanks for the follow up! Will continue to play with it.

What a great solution. I will use it, but...

I guess I found a serious security problem.

When logging ssh commands with '-vT', I can see the secret. The secret should be hard coded in the two_factor script.

I don't see the secret in the output when I run that command. It just says:

debug1: Remote: Forced command.

It seems that certain versions of OpenSSH do print out the command and parameters so I've updated the blog post to include a work-around

In the authorized_keys script, if instead of exec()ing SHELL you use SSH_ORIGINAL_COMMAND you won't break "ssh myhost <command>"

In the extended example it does actually use the SSH_ORIGINAL_COMMAND, will update the simple version too

In the extended example you're falling back to exec(SHELL) if SSH_ORIGINAL_COMMAND doesn't exist. Does sshd not set that to the login shell if no command is specified by the client?

SSH_ORIGINAL_COMMAND isn't in the ENV at all if no command was passed through

Right, that was what I asked in my other post. I assumed sshd would fill in the login shell there if nothing was passed as that is effectively what is being called but it seems not. I see you're doing exec(SHELL) to fix that.

Beware that this may break apps that use SSH as a transport protocol (like rsync and mercurial, depending on your setup of course).

You could set those up with separate identities authorized with forced commands, though I'm not sure how you would secure rsync from abuse.

The extended example 'should' work with those kinds of apps. The trivial example does not.

More specifically it checks for the SSH_ORIGINAL_COMMAND environment variable and executes it if it exists, thus making "ssh myhost <command>" work again.

+ port knocking via knockd and running sshd on a diff port is good.

I got a certificate warning when opening the page.

Interesting, would you mind letting me know which browser/version you're running? and the error message if possible?

I got the same thing on the default browser for Android 2.3, it shows the certificate was issued 9 17 2006 but expires 9 17 1936 (not sure if that's cert or CA) issued by startcom.

I got it with Dolphin browserr on Android 2.2, but didn't read it and can't get it anymore after I clicked "continue".