In the OpenSSH codebase experimental support for two-factor authentication using devices that support the protocol , developed by the alliance. U2F enables the creation of inexpensive hardware tokens to confirm the physical presence of a user, interacting via USB, Bluetooth, or NFC. Such devices are promoted as a means for two-factor authentication on websites, are already supported by major browsers, and are produced by various manufacturers, including Yubico, Feitian, Thetis, and Kensington.
To interact with the user presence-confirming devices, OpenSSH introduces a new key type ‘sk-ecdsa-sha2-nistp256@openssh.com’ (‘ecdsa-sk’), which uses the ECDSA (Elliptic Curve Digital Signature Algorithm) signing algorithm with the NIST P-256 curve and SHA-256 hash. Interaction procedures with tokens are placed in an intermediate library, which is loaded similarly to the PKCS#11 support library and serves as a wrapper around the library. , providing means for communication with tokens over USB (supports FIDO U2F/CTAP 1 and FIDO 2.0/CTAP 2 protocols). The intermediary library libsk-libfido2, prepared by OpenSSH developers, is included in the main libfido2 composition, as well as the HID driver To authenticate and generate a key, it is necessary to specify the 'SecurityKeyProvider' parameter in the settings or set the environment variable SSH_SK_PROVIDER, indicating the path to the external library libsk-libfido2.so (export SSH_SK_PROVIDER=/path/to/libsk-libfido2.so). There is an option to build OpenSSH with built-in support for the wrapper library (--with-security-key-builtin), in which case the 'SecurityKeyProvider=internal' parameter must be set.
To enable U2F, you can use the latest codebase snapshot from OpenSSH and the HEAD branch of the library , which already includes the necessary layer for OpenSSH.
Libfido2 supports operation in OpenBSD, Linux, macOS, and Windows.
To authenticate and generate a key, you must set the environment variable SSH_SK_PROVIDER, specifying the path to libsk-libfido2.so (export SSH_SK_PROVIDER=/path/to/libsk-libfido2.so), or define the library via the SecurityKeyProvider setting, and then run ‘ssh-keygen -t ecdsa-sk’ or, if keys are already created and configured, connect to the server using ‘ssh’. When running ssh-keygen, the generated key pair will be saved in ‘~/.ssh/id_ecdsa_sk’ and can be used just like 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 verified, while interaction with tokens occurs 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 descriptor of the key, forming the actual key only in conjunction with a secret sequence stored on the U2F token.
If the id_ecdsa_sk key falls into the hands of an attacker, they will also need access to the hardware token for authentication, without which the private key stored in the id_ecdsa_sk file is useless. Additionally, by default, any operations with keys (both during generation and authentication) require local confirmation of the user's physical presence, for example, touching the sensor on the token, which complicates remote attacks on systems with the token connected. As an additional layer of protection during the ssh-keygen startup, a password can also be set for access to the key file.
The U2F key can be added to the ssh-agent using "ssh-add ~/.ssh/id_ecdsa_sk", but the ssh-agent must be built with support for "ecdsa-sk" keys, and the libsk-libfido2 layer must be present, and the agent must be running on the system to which the token is connected.
A new type of keys "ecdsa-sk" has been added because the OpenSSH ecdsa key format differs from the U2F format for ECDSA digital signatures due to the presence of additional fields.
Source: opennet.ru
