OpenSSH already has initial support for two-factor authentication


OpenSSH the set of applications that allow encrypted communications over a network, using the SSH protocol has added experimental support for two-factor authentication to its code base, using devices that support the U2F protocol developed by the FIDO alliance.

For those unaware of U2F, they should know that, this is an open standard for making low-cost hardware security tokens. These are easily the cheapest way for users to get a hardware-backed key pair and there is a good range of manufacturers who sell them, includings Yubico, Feitian, Thetis, and Kensington.

Hardware-backed keys offer the advantage of being considerably more difficult to steal: an attacker generally has to steal the physical token (or at least persistent access to it) in order to steal the key.

Since there are several ways to talk to U2F devices, including USB, Bluetooth, and NFC, we didn't want to load OpenSSH with a ton of dependencies. Instead, we have delegated the task of communicating with the tokens to a small library of middleware that loads in similar to existing PKCS # 11 support.

OpenSSH now has experimental U2F / FIDO support, with U2F it is added as a new key type or «ecdsa-sk"For short (the" sk "stands for" security key ").

Procedures for interacting with tokens have been moved to an intermediate library, which is loaded by analogy with the library for PKCS # 11 support and is a link on the libfido2 library, which provides means to communicate with tokens via USB (FIDO U2F / CTAP 1 and FIDO 2.0 / CTAP 2).

Library intermediate libsk-libfido2 prepared by OpenSSH developers is included in the libfido2 kernel, as well as the HID driver for OpenBSD.

To enable U2F, a new portion of the code base from the OpenSSH repository can be used and the HEAD branch of the libfido2 library, which already includes the necessary layer for OpenSSH. Libfido2 supports working on OpenBSD, Linux, macOS, and Windows.

We have written a basic middleware for Yubico's libfido2 that is capable of talking to any standard USB HID U2F or FIDO2 token. The middleware. The source is hosted in the libfido2 tree, so building that and OpenSSH HEAD is enough to get started

The public key ( must be copied to the server in the file authorized_keys. On the server side, only a digital signature is verified and the interaction with the tokens is done on the client side (libsk-libfido2 does not need to be installed on the server, but the server must support the key type "ecdsa-sk »).

The generated private key (id_ecdsa_sk) is essentially a key descriptor that forms a real key only in combination with a secret sequence stored on the U2F token side.

If the key id_ecdsa_sk falls into the hands of the attacker, for authentication, he will also need to access the hardware token, without which the private key stored in the id_ecdsa_sk file is useless.

Moreover, by default, when key operations are performed (both during generation and authentication), local confirmation of the user's physical presence is requiredFor example, it is suggested to touch the sensor on the token, which makes it difficult to perform remote attacks on systems with a connected token.

In the beginning stage of ssh-keygen, other password can also be set to access the file with the key.

The U2F key can be added to ssh-agent through "ssh-add ~ / .ssh / id_ecdsa_sk", but ssh-agent must be compiled with key support ecdsa-sk, the libsk-libfido2 layer must be present and the agent must be running on the system to which token it is attached.

A new type of key has been added ecdsa-sk since the key format ecdsa OpenSSH differs from the U2F format for digital signatures ECDSA by the presence of additional fields.

If you want to know more about it you can consult the following link. 

The content of the article adheres to our principles of editorial ethics. To report an error click here!.

Be the first to comment

Leave a Comment

Your email address will not be published. Required fields are marked with *



  1. Responsible for the data: AB Internet Networks 2008 SL
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.