Over the past years system administrators had to learn that password authentication has its shortcomings. The protection level of password based authentication methods depends heavily on the password quality as well as the password handling of the users, where the latter is difficult to manage strictly. Public Key based authentication methods came to the rescue, and still help a lot, primarily to prevent wordlist based brute force attacks on passwords. For a long time, OpenSSH supports its own Secure Shell Public Key format as defined in RFC 4716 as well as the well-known x509 standard.

However, so far it was not possible to enforce true multi factor authentication in OpenSSH. In highly critical areas it may be desirable to protect an SSH service with more than just one authentication factor, may it be weak or strong. The security level of an authentication scheme can be enhanced when multiple factors are being combined, e.g. with ‘something you have’ and ‘something you know’. If an attacker gets hold of the factor ‘you have’, like the private key, he still needs to obtain ‘what you know’.

Of course, it has always been possible to protect the private key with a password, a strategy that is still recommendable. However, this only raises the security niveau of the one factor, but doesn’t introduce an independent second one. Besides, it does not allow for requiring another factor that is not a password, for instance a One Time Password mechanism (OTP).

The OpenSSH guys have introduced a new configuration option with the current version 6.2, called ‘AuthenticationMethods’. It specifies the authentication methods that must be successfully completed for a user to be granted access. This option must be followed by one or more comma-separated lists of authentication method names. Successful authentication requires completion of every method in at least one of these lists. Here’s a configuration example to enforce public key and password authentication for a user called ‘batman’:

Match User batman
      PasswordAuthentication yes
      PubkeyAuthentication yes
      AuthenticationMethods publickey,password publickey,keyboard-interactive

An SSH login session would now require two factors, as shown in the following client debug log (only the relevant lines are shown). Note how providing the correct key material as the first factor only results in the message “Authenticated with partial success.”

$ ssh -v puffy.wayne.com
debug1: Authentications that can continue: publickey
debug1: Offering ECDSA public key: /home/batman/.ssh/id_ecdsa
debug1: Server accepts key: pkalg ecdsa-sha2-nistp256 blen 104
debug1: read PEM private key done: type ECDSA
Authenticated with partial success.
debug1: Authentications that can continue: password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
batman@puffy.wayne.com's password:
debug1: Authentication succeeded (password).

Authenticated to puffy.wayne.com ([xxx.xxx.xx.xx]:22).
Last login: Wed Jul  3 11:50:06 2013 from x-xx-xx-xx-x.xxx.xx.xx

OpenBSD 5.3-stable (GENERIC) #5: Wed Jun 12 15:41:16 CEST 2013

Welcome to OpenBSD: The proactively secure Unix-like operating system.

batman@puffy.wayne.com:~>

Compass Security recommends using Multi Factor Authentication whenever an SSH service protects highly sensitive data or grants access to critical administrative functions via Internet. It ensures that a lost or stolen factor does not result in a full compromise of the system.