After four months of development, OpenSSH 8.7 has been released, an open implementation of the client and server for working with SSH 2.0 and SFTP protocols.
Key Changes:
- An experimental data transfer mode has been added to scp using the SFTP protocol instead of the traditionally used SCP/RCP protocol. SFTP employs more predictable name handling methods and does not use glob pattern processing through the shell on the remote host, which creates security issues. To enable SFTP in scp, the flag "-s" is proposed, but there are plans to switch to this protocol by default in the future.
- In sftp-server, SFTP protocol extensions have been implemented to reveal paths ~/ and ~user/, which are necessary for scp.
- The behavior of the scp utility has changed when copying files between two remote hosts (for example, "scp host-a:/path host-b:"), which is now by default done through an intermediate local host, similar to specifying the flag "-3". This approach prevents essential credentials from being sent to the first host and avoids triple interpretation of filenames in the shell (on the source, destination, and local systems), and also allows all authentication methods to be used when accessing remote hosts with SFTP, rather than just non-interactive methods. An option "-R" has been added to restore the old behavior.
- In ssh, a ForkAfterAuthentication setting has been added, corresponding to the flag "-f".
- In ssh, a StdinNull setting has been added, corresponding to the flag "-n".
- In ssh, a SessionType setting has been added, allowing modes corresponding to the flags "-N" (no session) and "-s" (subsystem).
- In ssh-keygen, it is now allowed to specify the key validity period in key files.
- In ssh-keygen, the flag "-Oprint-pubkey" has been added to output the full public key in the sshsig signature.
- In ssh and sshd, both the client and the server have switched to using a stricter configuration file parser that employs shell-like rules for handling quotes, spaces, and escape characters. The new parser also does not overlook previously existing allowances, such as skipping arguments in options (for example, the DenyUsers directive can no longer be left empty), unclosed quotes, and specifying multiple "=" characters.
- When using SSHFP DNS records for key verification, SSH now checks all matching records, rather than only those containing a specific type of digital signature.
- In ssh-keygen, when generating a FIDO key with the -Ochallenge option for hashing, an integrated layer is now used instead of libfido2 tools, allowing challenge sequences larger or smaller than 32 bytes.
- In sshd, when processing the directive environment="..." in authorized_keys files, only the first match is accepted, with a limit of 1024 environment variable names.
OpenSSH developers also warned about deprecating algorithms that use SHA-1 hashes due to the increasing effectiveness of prefix collision attacks (the cost of finding a collision is estimated at about $50,000). The next release plans to disable the use of the "ssh-rsa" public key signature algorithm by default, 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, 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 ease the transition to new algorithms, OpenSSH previously enabled the UpdateHostKeys setting by default, which allows clients to be automatically switched to more secure algorithms. This setting activates a special protocol extension called "hostkeys@openssh.com", enabling server after authentication to inform the client of all available host keys. The client can reflect these keys in its ~/.ssh/known_hosts file, allowing for host key updates and simplifying key changes on 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).
Source: opennet.ru
