OpenSSH 8.8 release with rsa-sha digital signature support disabled

The release of OpenSSH 8.8, an open implementation of the client and server for working over the SSH 2.0 and SFTP protocols, has been published. The release is notable for disabling by default the ability to use digital signatures based on RSA keys with a SHA-1 hash ("ssh-rsa").

The termination of support for "ssh-rsa" signatures is due to an increase in the effectiveness of collision attacks with a given prefix (the cost of choosing a collision is estimated at about 50 thousand dollars). To test if ssh-rsa is being used on your systems, you can try connecting via ssh with the "-oHostKeyAlgorithms=-ssh-rsa" option. Support for RSA signatures with SHA-256 and SHA-512 hashes (rsa-sha2-256/512), which are supported since OpenSSH 7.2, has been left unchanged.

In most cases, the deprecation of "ssh-rsa" support will not require any manual actions from users, since OpenSSH previously included the UpdateHostKeys setting by default, which automatically switches clients to more reliable algorithms. For migration, the protocol extension "[email protected]”, which allows the server, after passing authentication, to inform the client about all available host keys. When connecting to hosts with very old versions of OpenSSH on the client side, you can selectively return the ability to use "ssh-rsa" signatures by adding to ~/.ssh/config: Host old hostname HostkeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa

The new version also fixes a security issue caused by sshd, since the release of OpenSSH 6.2, incorrectly initializing the user's group when executing commands specified in the AuthorizedKeysCommand and AuthorizedPrincipalsCommand directives. These directives are supposed to ensure that commands are run under a different user, but in fact they inherited the list of groups used when starting sshd. Potentially, this behavior, in the presence of certain system settings, allowed the running handler to gain additional privileges in the system.

The new release note also published a warning about the intention to change the default scp utility to use SFTP instead of the legacy SCP/RCP protocol. SFTP uses more predictable name handling methods and does not use shell processing of glob patterns in filenames on the other host side, which creates security problems. In particular, when using SCP and RCP, the server decides which files and directories to send to the client, and the client only checks the correctness of the returned object names, which, in the absence of proper checks on the client side, allows the server to transfer other file names that differ from those requested. The SFTP protocol does not have these problems, but does not support expansion of special paths such as "~/". To resolve this difference, in the last release of OpenSSH, a new extension to the SFTP protocol was proposed in the SFTP server implementation to expand the ~/ and ~user/ paths.

Source: opennet.ru

Add a comment