After five months of development, the release of OpenSSH 8.5 is presented, an open implementation of the client and server for working with the SSH 2.0 and SFTP protocols.
The OpenSSH developers reminded about the upcoming deprecation of algorithms using SHA-1 hashes due to the increased efficiency of collision attacks with a given prefix (the cost of choosing a collision is estimated at about 50 thousand dollars). In one of the next 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 widely used in practice.
To test if ssh-rsa is being used on your systems, you can try connecting via ssh with the "-oHostKeyAlgorithms=-ssh-rsa" option. At the same time, disabling "ssh-rsa" digital signatures by default does not mean a complete rejection of the use of RSA keys, since in addition to SHA-1, the SSH protocol allows the use of other algorithms for calculating hashes. In particular, in addition to "ssh-rsa", it will still be possible to use "rsa-sha2-256" (RSA/SHA256) and "rsa-sha2-512" (RSA/SHA512) bundles.
To smooth the transition to new algorithms, OpenSSH 8.5 includes the UpdateHostKeys setting by default, which allows you to automatically switch clients to more reliable algorithms. With this setting, a special protocol extension "[email protected]β, which allows the server, after passing authentication, to inform the client about all available host keys. The client can reflect these keys in its ~/.ssh/known_hosts file, which allows you to organize the update of host keys and makes it easier to change keys on the server.
The use of UpdateHostKeys is subject to a few caveats that may be overridden in the future: the key must appear in the UserKnownHostsFile and not be used in the GlobalKnownHostsFile; the key must be present under only one name; the host key certificate must not be used; known_hosts must not be masked by hostname; the VerifyHostKeyDNS setting must be disabled; the UserKnownHostsFile setting must be active.
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).
Other changes:
- Security related changes:
- Fixed a vulnerability in ssh-agent caused by re-freeing an already freed area of ββmemory (double-free). The problem has been present since the release of OpenSSH 8.2 and can potentially be exploited if an attacker has access to the ssh-agent socket on the local system. The exploitation is complicated by the fact that only root and the original user have access to the socket. The most likely attack scenario is to redirect the agent to an account that is controlled by the attacker, or to a host on which the attacker has root access.
- Added protection to sshd from passing very large username parameters to the PAM subsystem, which allows blocking vulnerabilities in PAM (Pluggable Authentication Module) system modules. For example, the change prevents sshd from being used as a vector for exploiting a recently discovered Solaris root vulnerability (CVE-2020-14871).
- Changes potentially breaking compatibility:
- In ssh and sshd, an experimental key exchange method has been redesigned that is resistant to guessing on a quantum computer. Quantum computers are radically faster at solving the problem of decomposing a natural number into prime factors, which underlies modern asymmetric encryption algorithms and cannot be effectively solved on classical processors. The method used is based on the NTRU Prime algorithm, developed for post-quantum cryptosystems, and the X25519 elliptic curve key exchange method. Instead of [email protected] the method is now identified as [email protected] (algorithm sntrup4591761 replaced by sntrup761).
- In ssh and sshd, the order in which the supported digital signature algorithms are advertised has been changed. ED25519 is now offered first instead of ECDSA.
- In ssh and sshd, setting the TOS/DSCP quality of service for interactive sessions is now done before the TCP connection is established.
- Cipher support dropped from ssh and sshd [email protected], which is identical to aes256-cbc and was in use prior to RFC-4253 approval.
- By default, the CheckHostIP setting is disabled, which is of little use, but using it makes it much more difficult to rotate keys for hosts behind load balancers.
- PerSourceMaxStartups and PerSourceNetBlockSize settings have been added to sshd to limit the intensity of launching handlers in relation to the client address. The specified parameters allow you to more finely control the restriction on the launch of processes, compared to the general setting of MaxStartups.
- A new LogVerbose setting has been added to ssh and sshd, which allows you to forcefully raise the level of debug information dumped to the log, with the ability to filter by patterns, functions, and files.
- In ssh, when accepting a new host key, it is ensured that all host names and IP addresses associated with the key are displayed.
- In ssh, the UserKnownHostsFile=none option is allowed to disable the use of the known_hosts file when identifying host keys.
- Added KnownHostsCommand option to ssh_config to get known_hosts data from specified command output.
- Added PermitRemoteOpen option to ssh_config to allow limiting the destination when using the RemoteForward option with SOCKS.
- ssh for FIDO keys provides a PIN re-request in case of a digital signature operation failure due to an incorrect PIN and no PIN request from the user (for example, when it was not possible to obtain the correct biometric data and the device fell back to manual PIN entry).
- Support for additional system calls has been added to sshd's seccomp-bpf-based process isolation mechanism on the Linux platform.
- The contrib/ssh-copy-id utility has been updated.
Source: opennet.ru