After four months of development Release , an open implementation of the client and server for working over the SSH 2.0 and SFTP protocols.
A key improvement in the release of OpenSSH 8.2 is the ability to use two-factor authentication with 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, OpenSSH added new key types "ecdsa-sk" and "ed25519-sk", which use the digital signature algorithms ECDSA and Ed25519, in combination with a 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.
For authentication and key generation, you must specify the "SecurityKeyProvider" parameter in the settings or set the SSH_SK_PROVIDER environment variable, specifying 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 interlayer library (--with-security-key-builtin), in which case you need to set the "SecurityKeyProvider=internal" parameter.
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 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 new version of OpenSSH also announced the upcoming deprecation of algorithms using SHA-1 hashes due to the effectiveness of collision attacks with a given prefix (the cost of selecting a collision is estimated at about 45 thousand dollars). In one of the upcoming releases, they plan to disable by default the ability to use the ssh-rsa public key digital signature algorithm, which is mentioned in the original RFC for the SSH protocol and remains widespread in practice (to check the use of ssh-rsa in your systems, you can try to connect via ssh with "-oHostKeyAlgorithms=-ssh-rsa" option).
To smooth the transition to new algorithms in OpenSSH, in one of the next releases, the UpdateHostKeys setting will be enabled by default, which will automatically migrate clients to more reliable 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 8.2, the ability to connect using "ssh-rsa" is still available, but this algorithm has been removed from the CASignatureAlgorithms list, which defines the algorithms allowed for digitally signing new certificates. Similarly, the diffie-hellman-group14-sha1 algorithm has been removed from the default key exchange algorithms. It is noted that the use of SHA-1 in certificates is associated with additional risk, since the attacker has unlimited time to search for a collision for an existing certificate, while the attack time on host keys is limited by the connection timeout (LoginGraceTime).
ssh-keygen now defaults to the rsa-sha2-512 algorithm supported since OpenSSH 7.2, which can create compatibility issues when attempting to process OpenSSH 8.2-signed certificates on systems with older releases of OpenSSH (to workaround when signing can be explicitly specified "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, which allows you to include the contents of other files in the current position of the configuration file (glob masks are allowed when specifying a file name);
- Added "no-touch-required" option to ssh-keygen, disabling the need to physically confirm access to the token when generating a key;
- Added PubkeyAuthOptions directive to sshd_config to combine 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. By analogy, the "no-touch-required" option has been added to the authorized_keys file;
- Added "-O write-attestation=/path" option to ssh-keygen to write additional FIDO attestation certificates when generating keys. OpenSSH does not yet use these certificates, but they can later be used to verify that the key is placed in a trusted hardware store;
- In the settings of ssh and sshd through the IPQoS directive, it is now possible to set the traffic prioritization mode (Lower-Effort Per-Hop Behavior);
- In ssh, when setting the value "AddKeysToAgent=yes", if the key does not contain a field with a comment, it will be added to ssh-agent with the path to the key as a comment. IN
ssh-keygen and ssh-agent also now use PKCS#11 tags and an X.509 subject name instead of a library path as comments in the key; - Added the ability to export PEM for DSA and ECDSA keys to ssh-keygen;
- Added a new executable ssh-sk-helper used to isolate the FIDO/U2F token access library;
- Added "--with-zlib" build option to ssh and sshd to compile with zlib library support;
- In accordance with the requirement of RFC4253, the banner displayed upon connection is provided with a warning about blocking access due to exceeding the MaxStartups limits. To simplify diagnostics, the sshd process header, visible when using the ps utility, displays the number of currently authenticated connections and the state of the MaxStartups limit;
- In ssh and ssh-agent, when calling a program to display a prompt set via $SSH_ASKPASS, a flag with the prompt type is now additionally transmitted: "confirm" - confirmation dialog (yes / no), "none" - informational message, "blank" β password request;
- Added a new digital signature operation "find-principals" to ssh-keygen to search the allowed-signers file for the user associated with the specified digital signature;
- Improved support for isolating the sshd process on Linux using the seccomp mechanism: disabling IPC system calls, allowing clock_gettime64(), clock_nanosleep_time64, and clock_nanosleep().
Source: opennet.ru