Version 6.2 of the OpenSSH package was released on March 22, bringing with it the usual palette of new encryption and authentication schemes, administrative options, and bug fixes. The notable changes include improved granularity for existing options, but there are also brand new features—such as the ability to fetch authorized keys via an external command, and the ability to require multiple authentication methods when users log in through sshd. Because OpenSSH includes a flexible mechanism to invoke operating system authentication methods, this means sshd can require genuine multi-factor authentication, with hardware tokens or biometrics.

Answer first these questions three (or two)

The sshd daemon in OpenSSH is configured (by default) through the /etc/ssh/sshd_config file. 6.2 adds a new keyword, AuthenticationMethods, which takes one or more comma-separated lists of authentication methods as its argument (with the lists themselves separated by spaces). If only one list is supplied, users must successfully complete all of the methods—in the order listed—to be granted access. If several lists are provided, users need complete only one of the lists. For example, the line

    AuthenticationMethods ``publickey,password hostbased,publickey''

There are just four allowable methods: publickey, password, hostbased, and keyboard-interactive. That might sound a tad inflexible, but keyboard-interactive is a generic method that can trigger other mechanisms, such as BSD Auth, S/KEY, or Pluggable Authentication Modules (PAM). By appending the desired submechanism after a colon, such as keyboard-interactive:pam, one can add any PAM module to the mix—including modules that build on an entirely different authentication model, such as Kerberos, hardware security tokens, or perhaps face recognition. Naturally, PAM needs to be configured to specify the module of interest as well, via /etc/pam.conf or /etc/pam.d/sshd.

The salient point, of course, is that modules are available which rely on "something you have" or "something you are" authentication. Otherwise, requiring users to provide a public key and a password is not genuinely multi-factor authentication, since both factors are squarely in the "something you know" column. Granted, there is a gray area where public keys are concerned, since users do not memorize them, but the fact that exact digital copies can be made separates them from hardware tokens. Whether widespread ease-of-deployment through OpenSSH will reinvigorate the development and maintenance of hardware and biometric PAM modules remains an open question.

Key lookups

The second addition to sshd's authentication toolkit is the AuthorizedKeysCommand keyword. The command supplied as the argument to this keyword is invoked to fetch the key of the user attempting to authenticate. In previous releases, this key-fetching step was limited to looking up the user's key on the filesystem (in the file specified by the AuthorizedKeysFile keyword). By accepting a command instead, administrators can look up the incoming user's key in a database, or over (for example) LDAP.

OpenSSH imposes some restrictions on the program specified for AuthorizedKeysCommand; it will be passed one argument (the username of the user attempting to connect) and it must return output on stdout consisting of zero or more lines of public keys, formatted in the same manner used by the AuthorizedKeysFile. In addition, the command is run as the user specified in the AuthorizedKeysCommandUser directive, which the OpenSSH project advises be a dedicated account with no other role on the machine.

If AuthorizedKeysCommand fails to return a key that authenticates the user, then it falls back onto the old-fashioned local key lookup method, which allows for a safety net in the event that the command fails or the remote host queried is unavailable.

In a related feature, OpenSSH 6.2 also adds support for Key Revocation Lists (KRLs). KRLs are compact, binary files that can be generated by OpenSSH's ssh-keygen utility. The KRL specification allows for several formats, depending on the type of credential revoked. The file can list a plain-text public key, a key's SHA1 hash, a certificate's key ID string, or a 64-bit certificate serial number (in decimal, hexadecimal, or octal). When revoking certificates via serial number, the KRL can specify a range, which is what leads to a claim in the OpenSSH 6.2 release notes that KRL can be so compact that it takes "as little a one bit per certificate".

The multiple acceptable formats specified in the KRL format can simplify the task of revoking keys. Among other things, the ability to revoke a credential by its serial number or key ID alone—without the original in hand—makes it possible for an administrator to revoke a compromised key or certificate rapidly when fetching a copy of the complete credential might cost valuable time. In addition, it allows administrators to revoke keys or certificates that have been (or are feared) lost.

Encryption for all

The new sshd authentication features are not the only changes in OpenSSH 6.2, of course. There are several new ciphers, modes, and message authentication codes (MACs) supported, such as Galois/Counter Mode (GCM) for AES, the 128-bit flavor of Message Authentication Code using Universal Hashing (UMAC-128), and encrypt-then-MAC (EtM) mode for SSH 2. The latter alters the packet format, computing the MAC over the packet length and the entire encrypted packet, rather than over the plaintext data payload.

There is also a new option available for specifying TCP forwarding behavior in sshd. In previous releases, the only possible options were "yes" and "no"; 6.2 adds two more: "local" and "remote", which allow administrators to limit TCP forwarding to just local or just remote hosts. In addition, there are several new command-line switches for logging and interactive help, which should make OpenSSH easier to work with, even though they do not add new features. The prospect of multi-factor authentication with ssh may have the most far-reaching implications, but OpenSSH 6.2 includes plenty of practical updates as well.