{"id":101069,"date":"2021-08-20T22:22:44","date_gmt":"2021-08-20T20:22:44","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/reliz-openssh-8-7"},"modified":"2021-08-20T22:22:44","modified_gmt":"2021-08-20T20:22:44","slug":"reliz-openssh-8-7","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/reliz-openssh-8-7","title":{"rendered":"Release of OpenSSH 8.7","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
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. <\/p>\n
Key Changes: <\/p>\n
\n
An experimental data transfer mode using the SFTP protocol has been added to scp instead of the traditionally used SCP\/RCP protocols. SFTP employs more predictable methods for handling names and does not utilize shell-based glob pattern processing on the other host, which creates security issues. To enable SFTP in scp, the flag '-s' has been proposed, but there are plans to switch to this protocol by default in the future.\n
In sftp-server, SFTP protocol extensions have been implemented to reveal paths ~\/ and ~user\/, which are necessary for scp.\n
The behavior of the scp utility when copying files between two remote hosts (for example, 'scp host-a:\/path host-b:') has changed, now defaulting to a local intermediate host, similar to when using the '-3' flag. This approach avoids transmitting unnecessary credentials to the first host and triple interpretation of file names in the shell (on the source, receiver, and local system), and it allows for the use of all authentication methods when accessing remote hosts, not just non-interactive ones, when using SFTP. An option '-R' has been added to restore the old behavior.\n
A ForkAfterAuthentication setting has been added to ssh, corresponding to the '-f' flag.\n
A StdinNull setting has been added to ssh, corresponding to the '-n' flag.\n
A SessionType setting has been added to ssh, allowing modes corresponding to the '-N' (no session) and '-s' (subsystem) flags.\n
In ssh-keygen, it is now allowed to specify the key validity period in key files.\n
An '-Oprint-pubkey' flag has been added to ssh-keygen for outputting the complete public key as part of the sshsig signature.\n
In both ssh and sshd, both client and server have been transitioned to use a stricter parser for the configuration file, which employs shell-like rules for handling quotes, spaces, and escape characters. The new parser also does not overlook previous assumptions, such as the omission of arguments in options (for example, the DenyUsers directive cannot be left empty anymore), unclosed quotes, and the specification of multiple '=' characters.\n
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.\n
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.\n
In sshd, when processing the directive environment='\u2026' in authorized_keys files, the first match is now accepted with a limit of 1024 environment variable names. <\/ul>\n
The developers of OpenSSH also warned about the transition to deprecated algorithms that use SHA-1 hashes, due to the increasing efficiency of prefix collision attacks (the cost of finding a collision is estimated at around $50,000). In the next release, the ability to use the digital signature algorithm 'ssh-rsa', mentioned in the original RFC for the SSH protocol and still widely used in practice, will be disabled by default. <\/p>\n
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 in addition to SHA-1. In particular, besides 'ssh-rsa', you will still be able to use the 'rsa-sha2-256' (RSA\/SHA256) and 'rsa-sha2-512' (RSA\/SHA512) pairs. <\/p>\n