Take the 2-minute tour ×

It seems that they are mutually exclusive, as disabling one gives me the other, and vice versa. Two-factor auth for my ssh servers sounds really nice, so is there any way to accomplish this?

share|improve this question
Are you are not wanting to count passphrased ssh keys? –  Phillip Nordwall Jul 31 '12 at 17:57
Oh, right. I should have specified that. No, that doesn't count. I'd like the server to have to be authenticated against twice, not the client :-) –  Chris Blake Jul 31 '12 at 18:07
@ChrisBlake - why? What problem are you trying to solve? Can you be more specific? What's your threat model? What risk are you trying to defend against? –  D.W. Aug 1 '12 at 2:13
@D.W. Threat model for requiring this: working with people you don't trust to take security as seriously as you do. You want to make it impossible for someone to compromise your server if their laptop, with a carelessly unencrypted ssh key, is stolen. –  user18203 Dec 30 '12 at 4:19
@JaneDoe, if that's the problem, then this might be better solved through policy rather than a technical mechanism. Requiring a password on every login has major disadvantages, and it sounds counterproductive to me. I think it's better to just set an organizational policy requiring all your sysadmins to encrypt their private key with a passphrase. (If you don't trust your sysadmins to follow this policy, why are you letting them administer your systems?) –  D.W. Dec 31 '12 at 22:33

3 Answers 3

up vote 11 down vote accepted

With recent Fedora and RHEL 6 releases, you can use RequiredAuthentications2 pubkey,password to require both pubkey and password authentication. Usually this is done to require pubkey and 2-factor authentication token, not the user's password.

share|improve this answer
With these new releases, this is the new (and easiest) correct answer. –  Chris Blake May 18 '14 at 4:13

You can have both public-key and password authentication on the same server. If public-key authentication fails, it will go to password authentication.

As to requiring both, that's seems silly and counterproductive, and checking man sshd_config there isn't an option to do this.

Your ssh private key should have a secure passphrase. So if an attacker obtains your private key, they still can't do anything without first obtaining your passphrase. If they've compromised that passphrase (most likely with a keylogger; or from brute forcing an extremely weak passphrase) they can trivially also grab/brute force any memorized password.

If you really want, you could possibly setup something with say ForceCommand (e.g., only allow public-key authentication and then direct user to a shell that prompts for a password). I don't recommend this.

A better alternative if you want to limit exposure, is to have a firewall setup to limit IPs that can reach the ssh port; possibly with an additional VPN running on a server somewhere if you may need to tunnel from another computer at some point. You could also use something like knockd to open a hole in a firewall after a particular port-knocking pattern, though recognize that anyone eavesdropping on traffic could replay the knocking pattern to open up a port.

share|improve this answer
Right. I should have taken the hint from @Phillip's comment, since the private key already needs a password, it's already a form of two-factor auth. And yeah, I'm also going to set up a port knocking daemon, but I couldn't choose from the given implementations on the website. Thanks for the referral and answer. –  Chris Blake Jul 31 '12 at 18:39

I looked into this a little more and came up with the following.

You could use PAM for two factor authenticaion, but in doing so you won't be using SSH keys you will be using a different two factors.

For example, You could use google with their two factor authentication and use pam to authenticate, as described at


share|improve this answer
Right. Thanks for the link. +1 –  Chris Blake Jul 31 '12 at 19:48

Your Answer


