{"id":42941,"date":"2020-02-17T14:41:56","date_gmt":"2020-02-17T11:41:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/reliz-openssh-8-2-c-podderzhkoj-tokenov-dvuhfaktornoj-autentifikaczii-fido-u2f"},"modified":"2020-02-17T14:41:56","modified_gmt":"2020-02-17T11:41:56","slug":"reliz-openssh-8-2-c-podderzhkoj-tokenov-dvuhfaktornoj-autentifikaczii-fido-u2f","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/reliz-openssh-8-2-c-podderzhkoj-tokenov-dvuhfaktornoj-autentifikaczii-fido-u2f","title":{"rendered":"Release of OpenSSH 8.2 with support for FIDO\/U2F two-factor authentication tokens","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

After four months of development introduced<\/a><\/noindex> release OpenSSH 8.2<\/a><\/noindex>, an open implementation of a client and server for working with SSH 2.0 and SFTP protocols. <\/p>\n

A key improvement in the OpenSSH 8.2 release is the ability to use two-factor authentication via devices that support the U2F<\/a><\/noindex>, developed by the FIDO<\/a><\/noindex>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.<\/p>\n

To interact with devices confirming user presence, OpenSSH has added new key types «ecdsa-sk» and «ed25519-sk», which use the ECDSA and Ed25519 digital signature algorithms, along with the SHA-256 hash. The procedures for interacting with tokens have been moved to an intermediate library that loads similarly to the PKCS#11 support library and acts as a wrapper around the library. libfido2<\/a><\/noindex>, 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 enabled<\/a><\/noindex> the HID driver for OpenBSD.<\/a><\/noindex> 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.<\/p>\n

To authenticate and generate a key, you need to specify the «SecurityKeyProvider» parameter in the settings or set the SSH_SK_PROVIDER environment variable, indicating the path to the external library libsk-libfido2.so (export SSH_SK_PROVIDER=\/path\/to\/libsk-libfido2.so). It is possible to build OpenSSH with built-in support for the middleware library (—with-security-key-builtin), in which case you need to set the «SecurityKeyProvider=internal» parameter.
\nNext, you need to run «ssh-keygen -t ecdsa-sk» or, if the keys are already created and configured, connect to the server using «ssh». When running ssh-keygen, the created key pair will be saved in «~\/.ssh\/id_ecdsa_sk» and can be used like other keys. <\/p>\n

The public key (id_ecdsa_sk.pub) should be copied to the server into the authorized_keys file. On the server side, only the digital signature is verified, while the 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) essentially acts as a key descriptor, forming the actual key only in conjunction with the 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 to authenticate, as the saved private key in id_ecdsa_sk is useless without it. <\/p>\n

Furthermore, by default, any operations with keys (both during generation and authentication) require local confirmation of the user's physical presence, such as being prompted to touch the sensor on the token, which complicates remote attacks on systems with the connected token. As an additional layer of protection, a password can also be set for accessing the key file at the ssh-keygen startup stage. <\/p>\n

In the new version of OpenSSH, it has also been announced that algorithms using SHA-1 hashes will soon be classified as deprecated, due to increased<\/a><\/noindex> the effectiveness of collision attacks with a given prefix (the cost of finding a collision is estimated at about $45,000). In one of the upcoming releases, the ability to use the \u2018ssh-rsa\u2019 public key signature algorithm, which is mentioned in the original RFC for the SSH protocol and remains widely used in practice, will be disabled by default (to check for the usage of ssh-rsa in your systems, you can try to connect via ssh with the option \u2018-oHostKeyAlgorithms=-ssh-rsa\u2019).<\/p>\n

To smooth the transition to new algorithms in OpenSSH, the UpdateHostKeys setting will be enabled by default in one of the next releases, allowing clients to automatically switch to more secure algorithms. Recommended algorithms for migration include rsa-sha2-256\/512 based on RFC8332 RSA SHA-2 (supported since OpenSSH 7.2 and used by default), ssh-ed25519 (supported since OpenSSH 6.5), and ecdsa-sha2-nistp256\/384\/521 based on RFC5656 ECDSA (supported since OpenSSH 5.7).<\/p>\n

In OpenSSH version 8.2, the ability to connect using 'ssh-rsa' is still available, but this algorithm has been removed from the list of CASignatureAlgorithms, which defines the algorithms allowed for digital signatures of new certificates. Similarly, the algorithm diffie-hellman-group14-sha1 has been removed from the default supported key exchange algorithms. It is noted that using SHA-1 in certificates carries an additional risk, as an attacker has unlimited time to find a collision for an existing certificate, while the time to attack host keys is limited by the connection timeout (LoginGraceTime). <\/p>\n

When running ssh-keygen, the rsa-sha2-512 algorithm is now used by default, which has been supported since OpenSSH 7.2. This may create compatibility issues when trying to handle certificates signed in OpenSSH 8.2 on systems with older releases of OpenSSH (to bypass this issue when forming signatures, you can explicitly specify 'ssh-keygen -t ssh-rsa' or use the ecdsa-sha2-nistp256\/384\/521 algorithms, supported since OpenSSH 5.7).<\/p>\n

Other changes:<\/p>\n