63

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?

Michael come lately
  • 2,630
  • 2
  • 23
  • 39
chrisdotcode
  • 733
  • 1
  • 6
  • 6
  • 4
    Are you are not wanting to count passphrased ssh keys? – Phillip Nordwall Jul 31 '12 at 17:57
  • 6
    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 :-) – chrisdotcode 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 01 '12 at 02:13
  • 10
    @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. –  Dec 30 '12 at 04:19
  • 3
    @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
  • 1
    @D.W. The issue is that even if you encrypt a private key with a passphrase this can relatively easily be bruteforced offline. It's difficult to ensure that users will use a sufficiently complex passphrase that cannot be bruteforced today - virtually impossible to ensure it won't be bruteforced in future - pre-crypto, would we have imagined the amount of hashing power available today, what will be next. Stoping the passphrase being bruteforced by using a password on the server seems essential. – jme May 16 '22 at 09:16

6 Answers6

57

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.

Update: Now on RHEL / CentOS 7, and any system with a recent version of OpenSSH, you can use:

AuthenticationMethods "publickey,password" "publickey,keyboard-interactive"

It's also possible to use the Match directive to exclude IPs or Users.

Community
  • 1
mricon
  • 6,508
  • 25
  • 27
  • 2
    See @Jakuje answer here for more recent Linux distro key+password SSH setup. The name of config parameter has changed. – Mister_Tom Feb 18 '16 at 22:56
  • 2
    Would have been more sensible to mention the OpenSSH version instead of some vague range of major distro version. – 0xC0000022L Jun 05 '18 at 09:04
16

(cross posting SO answer with updated solution to these days)

If you read through the manual page for sshd_config(5), there is option AuthenticationMethods, which takes the list of methods you need to pass before you are granted access. Your required setup is:

AuthenticationMethods publickey,password

This method should work all the current Linux systems with recent openssh (openssh-6, openssh-7).

Older systems

The only exception I know about is RHEL 6 (openssh-5.3), which requires setting different option with same values (as described in the other answer):

RequiredAuthentications2 publickey,password
Community
  • 1
Jakuje
  • 5,759
  • 1
  • 22
  • 34
16

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.

dr jimbob
  • 39,312
  • 8
  • 94
  • 164
  • 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. – chrisdotcode Jul 31 '12 at 18:39
  • 2
    Consider the case when the attacker has taken control of a machine in which the user has used an authentication agent (e.g., ssh-agent) to cache the private key. The attacker doesn't have the passphrase, but can still use the private key until the agent flushes its cache. It's in this scenario that requiring the key and the login password can help. – Psychonaut Jun 22 '16 at 06:33
  • 5
    "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." True, but there is an additional reason for using a server-side password: prevent offline cracking. E.g. from a mobile device, 4 digits can be a secure additional authentication measure if it's locked out indefinitely after 3 attempts, but with a passphrase on the privkey you can't do lockout. – Luc Mar 06 '17 at 09:05
  • 1
    100% what @Luc says - offline cracking makes passphrase protected keys virtually useless without a good rotation/expiration policy and arguable dangerous as it lulls people into a false sense of security (like above). Furthermore, even with a passphrase, a skilled hacker can avoid a bruteforce by forcing a coredump on the ssh-agent (or putty or whatever) and having a nice unencrypted copy of the key (or passphrase) in a core file for use indefinitely. – jme May 16 '22 at 09:24
4

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

http://www.techrepublic.com/blog/opensource/two-factor-ssh-authentication-via-google-secures-linux-logins/2607

Phillip Nordwall
  • 1,024
  • 9
  • 13
3

The only solution that worked for me is to have what follows in the /etc/ssh/sshd_config (tested with a CentOS7):

PubkeyAuthentication yes 
AuthenticationMethods publickey password
AuthorizedKeysFile      .ssh/authorized_keys
PasswordAuthentication yes 
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes

Which means to have PAM enabled, to have enabled every line that concerns the publik key and, finally, to have AuthenticationMethods properly listing both methods. Please note that, despite what was written by Jakuje, you should not add a comma between publickey and password after AuthenticationMethods.

schroeder
  • 129,372
  • 55
  • 299
  • 340
Luca Scotto Lavina
  • 31
  • 3
  • 1
    You should add a comma between auth methods if you want those methods to be combined, i.e. publickey AND password (as in the question). In your example the behavior is different, - either publickey OR password will be accepted. – wombatonfire Nov 17 '19 at 16:11
  • I can't believe this worked for me. removing the comma between publickey and password allows to authenticate by either this or that. thanks for this solution – Viktova Dec 06 '19 at 14:47
-1

Yes. Access as a sudo user to Ubuntu first.

sudo nano /etc/ssh/sshd_config

Modify the file

PubkeyAuthentication yes

PasswordAuthentication yes


CTRL+X

Save Modified Buffer? Press Y and then Enter Restart SSH

 /etc/init.d/ssh restart

Do not exit without testing, using the standalone separate console.

Tested on Ubuntu 20.04.2 LTS

Rajib
  • 99
  • 1