After four months of development release , an open implementation of a client and server for working with SSH 2.0 and SFTP protocols.
A key improvement in the OpenSSH 8.2 release is the ability to use two-factor authentication via devices that support the , 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 devices confirming user presence, new key types 'ecdsa-sk' and 'ed25519-sk' have been added to OpenSSH, utilizing ECDSA and Ed25519 digital signature algorithms combined with the SHA-256 hash. Token interaction procedures have been moved to an intermediary library, which is loaded similarly to the library for PKCS#11 support, and serves as a wrapper over the , 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.
Next, you need to 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 saved in '~/.ssh/id_ecdsa_sk' and can be used similarly to other keys.
Next, you need to 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 created key pair will be saved in "~/.ssh/id_ecdsa_sk" and can be used similarly to 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 the interaction with tokens occurs on the client side (there is no need to install libsk-libfido2 on the server, but the server must support the key type 'ecdsa-sk'). The generated private key (id_ecdsa_sk) is essentially a descriptor of the key, 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 would also need access to the hardware token to pass authentication, without which the private key saved in the id_ecdsa_sk file is useless.
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.
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 efficiency of collision attacks with a defined prefix (the cost of finding a collision is estimated at approximately $45,000). In an upcoming release, the default option to use the ‘ssh-rsa’ public key digital signature algorithm will be disabled, which is mentioned in the original RFC for the SSH protocol and remains widely used in practice (to check the use of ssh-rsa in your systems, try connecting via ssh with the ‘-oHostKeyAlgorithms=-ssh-rsa’ option).
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).
In OpenSSH version 8.2, the ability to connect using 'ssh-rsa' is still retained, but this algorithm has been removed from the CASignatureAlgorithms list, which determines the algorithms allowed for the 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 poses an additional risk, as an attacker has unlimited time to find a collision for an existing certificate, whereas the time for attacks on host keys is limited by the connection timeout (LoginGraceTime).
When executing ssh-keygen, the rsa-sha2-512 algorithm is now applied by default, which has been supported since OpenSSH 7.2. This may create compatibility issues when trying to process certificates signed in OpenSSH 8.2 on systems with older releases of OpenSSH. To bypass the issue when creating signatures, you can explicitly specify "ssh-keygen -t ssh-rsa" or use the ecdsa-sha2-nistp256/384/521 algorithms, supported since OpenSSH 5.7.
Other changes:
- The Include directive has been added to sshd_config, allowing the inclusion of content from other files at the current position in the configuration file (glob patterns are permitted when specifying the file name).
- A new option, "no-touch-required," has been added to ssh-keygen, disabling the need for physical confirmation of access to the token when generating a key.
- The PubkeyAuthOptions directive has been added to sshd_config, combining various options related to public key authentication. Currently, only the "no-touch-required" flag is supported to skip the physical presence check when authorizing with a token. Similarly, the "no-touch-required" option has been added to the authorized_keys file.
- The option "-O write-attestation=/path" has been added to ssh-keygen, allowing for the writing of additional FIDO attestation certificates when generating keys. OpenSSH does not currently use these certificates, but they may be utilized in the future to verify the placement of the key in a trusted hardware store.
- In the ssh and sshd settings, the IPQoS directive now allows for the configuration of traffic prioritization modes. (Lower-Effort Per-Hop Behavior);
- In ssh, when setting the value "AddKeysToAgent=yes", if the key does not contain a comment field, it will be added to the ssh-agent with the comment being the key's path. In
ssh-keygen and ssh-agent, PKCS#11 tags and X.509 subject names are also now used as comments in the key instead of the library path. - The ability to export PEM for DSA and ECDSA keys has been added to ssh-keygen.
- A new executable file, ssh-sk-helper, has been introduced for isolating the FIDO/U2F token access library.
- An assembly option "--with-zlib" has been added to ssh and sshd for compiling with zlib library support.
- In accordance with the requirement of RFC4253, the banner displayed upon connection includes a warning about access being blocked due to exceeding the MaxStartups limits. To simplify diagnostics, the sshd process header, visible when using the ps utility, now shows the number of currently authenticated connections and the status of the MaxStartups limit.
- In ssh and ssh-agent, when invoking the program for displaying prompts set through $SSH_ASKPASS, an additional flag is now passed indicating the type of prompt: 'confirm' — confirmation dialog (yes/no), 'none' — informational message, 'blank' — password prompt.
- A new operation with digital signatures 'find-principals' has been added to ssh-keygen for searching the user's allowed-signers file associated with a specified digital signature.
- Improved support for isolating the sshd process in Linux using the seccomp mechanism: IPC system calls are disallowed, while clock_gettime64(), clock_nanosleep_time64, and clock_nanosleep() are allowed.
Source: opennet.ru
