After five months of development, the release of OpenSSH 8.5 has been announced, an open implementation of the client and server for SSH 2.0 and SFTP protocols.
OpenSSH developers have reminded users of the upcoming deprecation of algorithms using SHA-1 hashes due to the increasing effectiveness of prefix collision attacks (the cost of finding a collision is estimated at around $50,000). In one of the forthcoming releases, the default option to use the OpenSSH public key signature algorithm 'ssh-rsa' will be disabled, which is mentioned in the original RFC for SSH and remains widely used in practice.
To check the use of ssh-rsa in your systems, you can try connecting via ssh with the option '-oHostKeyAlgorithms=-ssh-rsa'. However, disabling the ssh-rsa digital signatures by default does not mean a complete rejection of RSA keys, as the SSH protocol allows the use of other hashing algorithms besides SHA-1. Specifically, in addition to 'ssh-rsa', it will remain possible to use the pairs 'rsa-sha2-256' (RSA/SHA256) and 'rsa-sha2-512' (RSA/SHA512).
To facilitate the transition to new algorithms in OpenSSH 8.5, the UpdateHostKeys setting is enabled by default, which automatically transitions clients to more secure algorithms. This setting activates a special protocol extension 'hostkeys@openssh.com', allowing the server to inform the client of all available host keys after authentication. The client can reflect these keys in its file ~/ .ssh / known_hosts, allowing for host key updates and simplifying key changes. server.
The use of UpdateHostKeys is limited by several caveats that may be lifted in the future: the key must be mentioned in UserKnownHostsFile and not used in GlobalKnownHostsFile; the key must appear under only one name; a host key certificate must not be used; name masks must not be used in known_hosts; the VerifyHostKeyDNS setting must be disabled; and the UserKnownHostsFile parameter must be active.
Among the recommended algorithms for migration are 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:
- A vulnerability caused by double-free memory area release has been fixed in ssh-agent. The issue manifests since the release of OpenSSH 8.2 and could potentially be exploited if an attacker has access to the ssh-agent socket on the local system. Exploiting this is complicated since only root and the originating user have access to the socket. The most likely attack scenario involves redirecting the agent to an account controlled by the attacker or to a host where the attacker has root access.
- In sshd, a safeguard against passing very large parameters with usernames to the PAM subsystem has been added, which helps block vulnerabilities in PAM (Pluggable Authentication Module) system modules. For example, this change prevents sshd from being used as a vector for exploiting a recently discovered root vulnerability in Solaris (CVE-2020-14871).
- Changes that may break compatibility:
- In ssh and sshd, an experimental key exchange method resistant to quantum computer guessing has been redesigned. Quantum computers can solve the factorization of natural numbers into prime factors much faster, which underlies modern asymmetric encryption algorithms and is effectively unsolvable on classical processors. The method used is based on the NTRU Prime algorithm developed for post-quantum cryptosystems, along with a key exchange method based on elliptic curves X25519. Instead of sntrup4591761x25519-sha512@tinyssh.org, the method is now identified as sntrup761x25519-sha512@openssh.com (the sntrup4591761 algorithm has been replaced with sntrup761).
- In ssh and sshd, the order of announcing supported digital signature algorithms has been changed. ED25519 is now offered first instead of ECDSA.
- In ssh and sshd, the quality of service parameters TOS/DSCP for interactive sessions is now set before establishing the TCP connection.
- In ssh and sshd, support for the cipher rijndael-cbc@lysator.liu.se, which is identical to aes256-cbc and was used before the RFC-4253 approval, has been discontinued.
- The CheckHostIP parameter is disabled by default, which has minimal benefits, but its usage significantly complicates key rotation for hosts behind load balancers.
- New settings PerSourceMaxStartups and PerSourceNetBlockSize have been added in sshd to limit the intensity of handler start-ups based on the client address. These parameters allow for finer control over process start limitations compared to the general MaxStartups setting.
- A new LogVerbose setting has been added in ssh and sshd, allowing for forced elevation of the logging level of debug information, with filtering options based on patterns, functions, and files.
- When accepting a new host key in ssh, all associated host names are displayed, (the key to connect to is specified, and iroh finds the associated host and establishes an encrypted connection using the QUIC protocol). Direct P2P connections are established whenever possible, but if not, it falls back to using relays, which are also employed for host discovery by keys. You can run your own relay or connect to public relays supported by the community., associated with the key.
- In ssh, the option UserKnownHostsFile=none is now allowed to disable the use of the known_hosts file during host key identification.
- In ssh_config for ssh, a new KnownHostsCommand setting has been added, allowing for retrieval of known_hosts data from the output of a specified command.
- In ssh_config for ssh, the PermitRemoteOpen option has been added, allowing for destination restriction when using the RemoteForward option with SOCKS.
- In ssh, for FIDO keys, a PIN re-prompt is ensured in case of a digital signature operation failure due to an incorrect PIN and the absence of a PIN prompt for the user (for example, when biometric data could not be accurately captured and the device reverted to manual PIN entry).
- In sshd, support for additional system calls has been added to the seccomp-bpf-based process isolation mechanism on the Linux platform.
- The contrib/ssh-copy-id utility has been updated.
Source: opennet.ru
