Hey,
I'm trying to lock down a few of our servers and I wondered if it was possible to set up "2 factor" authentication for some accounts on the server.
By 2 factor authentication I mean one could only log on if;
1) the server already had the clients id_rsa.pub in it's authorized keys
and
2) the user knew the password
But I only want to do it for some user accounts (I.E. we have nagios and git accounts which we want to authenticate with public keys only)
Is this even possible? Any advice on where to start?
-Sam

Hi Sam,

just to paraphrase your thought; you want your server to only accept any ssh connection from clients that matched 1) private/public key OR 2) password, and you want to deny access from any client that is not explicitly allowed to log in through ssh.

If this is the case, you can add to your server's sshd_config with the following rule :

AllowUsers user1 user2 user3

Hope it may helped you.


----
sibe

Sorry maybe I didn't explain clearly enough,
the server should only accept connections from clients that matched both the private/public key in ~/.ssh/authorized-keys AND had the password.
-Sam

You can use login_duo to add two-factor auth to specific SSH pubkeys you want to add a secondary challenge to:

http://blog.duosecurity.com/2011/04/...tion-for-unix/

Or enable it system-wide, to protect any SSH login (using passwords OR pubkeys, or anything else :-)

1 members found this post helpful.

Brilliant!
Exactly what I was looking for, thanks

Can I ask why a key protected by a passphrase wasn't sufficient?

Short answer, if it's possible why not?
We have some important servers that contain very sensitive information (Think emails, private internal software, security keys etc.) so we're trying to add every possible security measure. This way the only way to log in is if one has access to computers that have already been authorized and knows the password.

Oh, I do get the need for having decent login security. I guess to my way of thinking, the duo security approach isn't all that different from having keys with strong passphrases. In both cases you need the user to know something besides the computer to login from.

Depends on circumstances (primarily: how keys are generated and distributed), but the problem is it's not easy to enforce strong passphrases on private keys. With shell account passwords, on the other hand, it is trivial to require and enforce certain criteria -- via pam_passwdqc(8) or pam_cracklib(8).

I wrote a blog post about this today :-) http://blog.duosecurity.com/2011/04/...call-you-back/

Quick summary: SSH keys are often used in ways that lead to serious breaches (e.g. sharing private keys among admins, or from a shared account on a bastion host). For many scenarios (e.g. managing lots of machines, or multiple admins, or extremely sensitive data), it pays to have a way to centralize management of those credentials.

I agree, users can't be trusted to create decent passphrases. I was assuming that users would be given pre-made keys so that wouldn't be an issue. That said, centralization via PAM is probably easier on the IT staff.

Again, don't get me wrong, I do understand that users are almost always the weakest link in the security chain. I guess what bugs me a little about the login_duo approach is that you're now trusting a 3rd party with part of your critical security. That might be a naive reaction on my part, but it still bugs me.

I always add an "AllowUsers" line in sshd_config. A nice side effect is that log in attempts from system users is blocked. Something else to look at is a from= field in the authorized keys entries. This will limit where the user can connect from.

Protecting the users private key with a strong passphrase is still important. Unfortunately, this merely unlocks the clients private key, and the user could circumvent it with keygen. Also, users logging in with Putty on Windows may not have the private key user read-only protected.