To the OpenSSH codebase experimental support for two-factor authentication using devices that support the protocol , developed by the alliance . U2F allows you to create low-cost hardware tokens to confirm the physical presence of the user, with which interaction is made via USB, Bluetooth or NFC. These devices are being promoted as a means of two-factor authentication on websites, are already supported by major browsers, and are available from various manufacturers, including Yubico, Feitian, Thetis, and Kensington.
To interact with devices that confirm the user's presence, a new type of keys has been added to OpenSSH "[email protected]β (βecdsa-skβ), which uses the Elliptic Curve Digital Signature Algorithm (ECDSA) with NIST P-256 Elliptic Curve and SHA-256 hash. The procedures for interacting with tokens are moved to an intermediate library, which is loaded similarly to the library for PKCS # 11 support and is a binding over the library , which provides means for communicating with tokens over USB (supports FIDO U2F/CTAP 1 and FIDO 2.0/CTAP 2 protocols). Prepared by the OpenSSH developers, the intermediate library libsk-libfido2 into the main composition of libfido2, like for OpenBSD.
To enable U2F, you can use a fresh snippet of the codebase from OpenSSH and the HEAD branch of the library , which already includes the layer necessary for OpenSSH.
Libfido2 supports OpenBSD, Linux, macOS and Windows.
To authenticate and generate a key, you must set the SSH_SK_PROVIDER environment variable, specifying the path to libsk-libfido2.so (export SSH_SK_PROVIDER=/path/to/libsk-libfido2.so) in it, or define the library through the SecurityKeyProvider setting, then run "ssh- keygen -t ecdsa-sk" or, if the keys have already been created and configured, connect to the server using "ssh". When running ssh-keygen , the generated key pair will be stored in "~/.ssh/id_ecdsa_sk" and can be used in the same way as other keys.
The public key (id_ecdsa_sk.pub) should be copied to the server in the authorized_keys file. On the server side, only the digital signature is checked, and interaction with tokens is done on the client side (libsk-libfido2 does not need to be installed on the server, but the server must support the "ecdsa-sk" key type). The generated private key (id_ecdsa_sk) is essentially a key descriptor that forms a real key only in combination with the secret sequence stored on the side of the U2F token.
If the id_ecdsa_sk key falls into the hands of an attacker, in order to pass authentication, he will also need to gain access to a hardware token, without which the private key stored in the id_ecdsa_sk file is useless. In addition, by default, when performing any operations with keys (both during generation and during authentication), local confirmation of the user's physical presence is required, for example, it is suggested to touch the sensor on the token, which makes it difficult to carry out remote attacks on systems with a connected token. As another line of defense, the ssh-keygen startup step can also be given a password to access the key file.
The U2F key can be added to the ssh-agent via "ssh-add ~/.ssh/id_ecdsa_sk", but the ssh-agent must be built to support "ecdsa-sk" keys, the libsk-libfido2 layer must be present, and the agent must be running on the system The token is attached to.
A new key type "ecdsa-sk" has been added because the OpenSSH ecdsa key format differs from the U2F format for ECDSA digital signatures by the presence of additional fields.
Source: opennet.ru