OpenSSH 8.7 release

After four months of development, the release of OpenSSH 8.7 is presented, an open implementation of the client and server for working with the SSH 2.0 and SFTP protocols.

Major changes:

  • Added experimental data transfer mode to scp using the SFTP protocol instead of the traditional SCP/RCP protocol. SFTP uses more predictable name handling methods and does not use glob processing through the shell on the other host side, which creates security problems. The "-s" flag has been proposed to enable SFTP in scp, but it is planned to switch to this protocol by default in the future.
  • sftp-server implements SFTP protocol extensions to expand the ~/ and ~user/ paths, which is necessary for scp.
  • The scp utility changed the behavior 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, as with the "-3" flag. This approach allows you to avoid passing extra credentials to the first host and triple interpretation of file names in the shell (on the source, destination and local system), and when using SFTP, it allows you to use all authentication methods when accessing remote hosts, and not just non-interactive methods . Added "-R" option to restore old behavior.
  • Added ForkAfterAuthentication setting to ssh, corresponding to the "-f" flag.
  • Added StdinNull setting to ssh, corresponding to the "-n" flag.
  • A SessionType setting has been added to ssh, through which you can set the modes corresponding to the "-N" (no session) and "-s" (subsystem) flags.
  • In ssh-keygen, it is allowed to specify the key expiration interval in key files.
  • Added "-Oprint-pubkey" flag to ssh-keygen to output the full public key as part of the sshsig signature.
  • In ssh and sshd, both client and server have been moved to use a more strict configuration file parser that uses shell-like rules for handling quotes, spaces, and escape characters. The new parser also does not ignore previous assumptions, such as omitting arguments in options (for example, you can no longer leave the DenyUsers directive empty), unclosed quotes, and specifying multiple "=" characters.
  • When using SSHFP DNS records when verifying keys, ssh now checks all matching records, not just those containing a certain type of digital signature.
  • In ssh-keygen, when generating a FIDO key with the -Ochallenge option, hashing now uses the built-in middleware instead of libfido2 tools, which allows the use of challenge sequences larger or smaller than 32 bytes.
  • In sshd, when processing the environment="..." directive in authorized_keys files, it now accepts the first match and has a limit of 1024 environment variable names.

OpenSSH developers have also warned about the deprecation of algorithms using SHA-1 hashes due to the increased efficiency of prefixed collision attacks (estimated cost of collision brute force is about $50). In the next release, it is planned 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 in OpenSSH, the UpdateHostKeys setting was previously enabled 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).

Source: opennet.ru

Add a comment