dwww Home | Show directory contents | Find package

openssh (1:9.5p1-1) experimental; urgency=medium

  OpenSSH 9.5p1 includes a number of changes that may affect existing
  configurations:

   * ssh-keygen(1): generate Ed25519 keys by default. Ed25519 public keys
     are very convenient due to their small size. Ed25519 keys are specified
     in RFC 8709 and OpenSSH has supported them since version 6.5 (January
     2014).

   * sshd(8): the Subsystem directive now accurately preserves quoting of
     subsystem commands and arguments. This may change behaviour for exotic
     configurations, but the most common subsystem configuration
     (sftp-server) is unlikely to be affected.

 -- Colin Watson <cjwatson@debian.org>  Thu, 23 Nov 2023 17:38:07 +0000

openssh (1:9.4p1-1) unstable; urgency=medium

  OpenSSH 9.4p1 includes a number of changes that may affect existing
  configurations:

   * ssh-agent(1): PKCS#11 modules must now be specified by their full
     paths. Previously dlopen(3) could search for them in system library
     directories.

 -- Colin Watson <cjwatson@debian.org>  Sat, 02 Sep 2023 21:02:53 +0100

openssh (1:9.3p2-1) unstable; urgency=high

  OpenSSH 9.3p2 includes a number of changes that may affect existing
  configurations:

   * ssh-agent(8): the agent will now refuse requests to load PKCS#11
     modules issued by remote clients by default. A flag has been added to
     restore the previous behaviour "-Oallow-remote-pkcs11".

     Note that ssh-agent(8) depends on the SSH client to identify requests
     that are remote. The OpenSSH >=8.9 ssh(1) client does this, but
     forwarding access to an agent socket using other tools may circumvent
     this restriction.

 -- Colin Watson <cjwatson@debian.org>  Wed, 19 Jul 2023 21:57:53 +0100

openssh (1:9.2p1-1) unstable; urgency=medium

  OpenSSH 9.2 includes a number of changes that may affect existing
  configurations:

   * ssh(1): add a new EnableEscapeCommandline ssh_config(5) option that
     controls whether the client-side ~C escape sequence that provides a
     command-line is available. Among other things, the ~C command-line
     could be used to add additional port-forwards at runtime.

     This option defaults to "no", disabling the ~C command-line that was
     previously enabled by default. Turning off the command-line allows
     platforms that support sandboxing of the ssh(1) client (currently only
     OpenBSD) to use a stricter default sandbox policy.

 -- Colin Watson <cjwatson@debian.org>  Wed, 08 Feb 2023 10:36:06 +0000

openssh (1:9.1p1-1) unstable; urgency=medium

  OpenSSH 9.1 includes a number of changes that may affect existing
  configurations:

   * ssh(1), sshd(8): SetEnv directives in ssh_config and sshd_config are
     now first-match-wins to match other directives. Previously if an
     environment variable was multiply specified the last set value would
     have been used.

   * ssh-keygen(8): ssh-keygen -A (generate all default host key types) will
     no longer generate DSA keys, as these are insecure and have not been
     used by default for some years.

 -- Colin Watson <cjwatson@debian.org>  Mon, 14 Nov 2022 16:35:59 +0000

openssh (1:9.0p1-1) unstable; urgency=medium

  OpenSSH 9.0 includes a number of changes that may affect existing
  configurations:

   * This release switches scp(1) from using the legacy scp/rcp protocol to
     using the SFTP protocol by default.

     Legacy scp/rcp performs wildcard expansion of remote filenames (e.g.
     "scp host:* .") through the remote shell. This has the side effect of
     requiring double quoting of shell meta-characters in file names
     included on scp(1) command-lines, otherwise they could be interpreted
     as shell commands on the remote side.

     This creates one area of potential incompatibility: scp(1) when using
     the SFTP protocol no longer requires this finicky and brittle quoting,
     and attempts to use it may cause transfers to fail. We consider the
     removal of the need for double-quoting shell characters in file names
     to be a benefit and do not intend to introduce bug-compatibility for
     legacy scp/rcp in scp(1) when using the SFTP protocol.

     Another area of potential incompatibility relates to the use of remote
     paths relative to other user's home directories, for example - "scp
     host:~user/file /tmp". The SFTP protocol has no native way to expand a
     ~user path. However, sftp-server(8) in OpenSSH 8.7 and later support a
     protocol extension "expand-path@openssh.com" to support this.

     In case of incompatibility, the scp(1) client may be instructed to use
     the legacy scp/rcp using the -O flag.

 -- Colin Watson <cjwatson@debian.org>  Sat, 09 Apr 2022 14:14:10 +0100

openssh (1:8.8p1-1) unstable; urgency=medium

  OpenSSH 8.8 includes a number of changes that may affect existing
  configurations:

   * This release disables RSA signatures using the SHA-1 hash algorithm by
     default. This change has been made as the SHA-1 hash algorithm is
     cryptographically broken, and it is possible to create chosen-prefix
     hash collisions for <USD$50K.

     For most users, this change should be invisible and there is no need to
     replace ssh-rsa keys. OpenSSH has supported RFC8332 RSA/SHA-256/512
     signatures since release 7.2 and existing ssh-rsa keys will
     automatically use the stronger algorithm where possible.

     Incompatibility is more likely when connecting to older SSH
     implementations that have not been upgraded or have not closely tracked
     improvements in the SSH protocol. For these cases, it may be necessary
     to selectively re-enable RSA/SHA1 to allow connection and/or user
     authentication via the HostkeyAlgorithms and PubkeyAcceptedAlgorithms
     options. For example, the following stanza in ~/.ssh/config will enable
     RSA/SHA1 for host and user authentication for a single destination
     host:

         Host old-host
             HostkeyAlgorithms +ssh-rsa
             PubkeyAcceptedAlgorithms +ssh-rsa

     We recommend enabling RSA/SHA1 only as a stopgap measure until legacy
     implementations can be upgraded or reconfigured with another key type
     (such as ECDSA or Ed25519).

 -- Colin Watson <cjwatson@debian.org>  Tue, 15 Feb 2022 19:20:21 +0000

openssh (1:8.7p1-1) unstable; urgency=medium

  OpenSSH 8.7 includes a number of changes that may affect existing
  configurations:

   * scp(1): this release changes the behaviour of remote to remote copies
     (e.g. "scp host-a:/path host-b:") to transfer through the local host by
     default. This was previously available via the -3 flag. This mode
     avoids the need to expose credentials on the origin hop, avoids
     triplicate interpretation of filenames by the shell (by the local
     system, the copy origin and the destination) and, in conjunction with
     the SFTP support for scp(1) mentioned below, allows use of all
     authentication methods to the remote hosts (previously, only
     non-interactive methods could be used). A -R flag has been added to
     select the old behaviour.

   * ssh(1)/sshd(8): both the client and server are now using a stricter
     configuration file parser. The new parser uses more shell-like rules
     for quotes, space and escape characters. It is also more strict in
     rejecting configurations that include options lacking arguments.
     Previously some options (e.g. DenyUsers) could appear on a line with no
     subsequent arguments. This release will reject such configurations. The
     new parser will also reject configurations with unterminated quotes and
     multiple '=' characters after the option name.

   * ssh(1): when using SSHFP DNS records for host key verification, ssh(1)
     will verify all matching records instead of just those with the
     specific signature type requested. This may cause host key verification
     problems if stale SSHFP records of a different or legacy signature type
     exist alongside other records for a particular host. bz#3322

   * ssh-keygen(1): when generating a FIDO key and specifying an explicit
     attestation challenge (using -Ochallenge), the challenge will now be
     hashed by the builtin security key middleware. This removes the
     (undocumented) requirement that challenges be exactly 32 bytes in
     length and matches the expectations of libfido2.

   * sshd(8): environment="..." directives in authorized_keys files are now
     first-match-wins and limited to 1024 discrete environment variable
     names.

  OpenSSH 8.5 includes a number of changes that may affect existing
  configurations:

   * ssh(1), sshd(8): this release changes the first-preference signature
     algorithm from ECDSA to ED25519.

   * ssh(1), sshd(8): set the TOS/DSCP specified in the configuration for
     interactive use prior to TCP connect. The connection phase of the SSH
     session is time-sensitive and often explicitly interactive.  The
     ultimate interactive/bulk TOS/DSCP will be set after authentication
     completes.

   * ssh(1), sshd(8): remove the pre-standardization cipher
     rijndael-cbc@lysator.liu.se. It is an alias for aes256-cbc before it
     was standardized in RFC4253 (2006), has been deprecated and disabled by
     default since OpenSSH 7.2 (2016) and was only briefly documented in
     ssh.1 in 2001.

   * ssh(1), sshd(8): update/replace the experimental post-quantum hybrid
     key exchange method based on Streamlined NTRU Prime coupled with
     X25519.

     The previous sntrup4591761x25519-sha512@tinyssh.org method is replaced
     with sntrup761x25519-sha512@openssh.com. Per its designers, the
     sntrup4591761 algorithm was superseded almost two years ago by
     sntrup761.

     (note this both the updated method and the one that it replaced are
     disabled by default)

   * ssh(1): disable CheckHostIP by default. It provides insignificant
     benefits while making key rotation significantly more difficult,
     especially for hosts behind IP-based load-balancers.

 -- Colin Watson <cjwatson@debian.org>  Sat, 06 Nov 2021 12:23:47 +0000

openssh (1:8.4p1-1) unstable; urgency=medium

  OpenSSH 8.4 includes a number of changes that may affect existing
  configurations:

   * ssh-keygen(1): the format of the attestation information optionally
     recorded when a FIDO key is generated has changed. It now includes the
     authenticator data needed to validate attestation signatures. 

   * The API between OpenSSH and the FIDO token middleware has changed and
     the SSH_SK_VERSION_MAJOR version has been incremented as a result.
     Third-party middleware libraries must support the current API version
     (7) to work with OpenSSH 8.4.

 -- Colin Watson <cjwatson@debian.org>  Sun, 18 Oct 2020 12:07:48 +0100

openssh (1:8.3p1-1) unstable; urgency=medium

  OpenSSH 8.3 includes a number of changes that may affect existing
  configurations:

  * sftp(1): reject an argument of "-1" in the same way as ssh(1) and scp(1)
    do instead of accepting and silently ignoring it.

 -- Colin Watson <cjwatson@debian.org>  Sun, 07 Jun 2020 13:44:04 +0100

openssh (1:8.2p1-1) unstable; urgency=medium

  OpenSSH 8.2 includes a number of changes that may affect existing
  configurations:

   * ssh(1), sshd(8), ssh-keygen(1): This release removes the "ssh-rsa"
     (RSA/SHA1) algorithm from those accepted for certificate signatures
     (i.e.  the client and server CASignatureAlgorithms option) and will use
     the rsa-sha2-512 signature algorithm by default when the ssh-keygen(1)
     CA signs new certificates.

     Certificates are at special risk to SHA1 collision vulnerabilities as
     an attacker has effectively unlimited time in which to craft a
     collision that yields them a valid certificate, far more than the
     relatively brief LoginGraceTime window that they have to forge a host
     key signature.

     The OpenSSH certificate format includes a CA-specified (typically
     random) nonce value near the start of the certificate that should make
     exploitation of chosen-prefix collisions in this context challenging,
     as the attacker does not have full control over the prefix that
     actually gets signed. Nonetheless, SHA1 is now a demonstrably broken
     algorithm and further improvements in attacks are highly likely.

     OpenSSH releases prior to 7.2 do not support the newer RSA/SHA2
     algorithms and will refuse to accept certificates signed by an OpenSSH
     8.2+ CA using RSA keys unless the unsafe algorithm is explicitly
     selected during signing ("ssh-keygen -t ssh-rsa").  Older
     clients/servers may use another CA key type such as ssh-ed25519
     (supported since OpenSSH 6.5) or one of the ecdsa-sha2-nistp256/384/521
     types (supported since OpenSSH 5.7) instead if they cannot be upgraded.

   * ssh(1), sshd(8): Remove diffie-hellman-group14-sha1 from the default
     key exchange proposal for both the client and server.

   * ssh-keygen(1): The command-line options related to the generation and
     screening of safe prime numbers used by the
     diffie-hellman-group-exchange-* key exchange algorithms have changed.
     Most options have been folded under the -O flag.

   * sshd(8): The sshd listener process title visible to ps(1) has changed
     to include information about the number of connections that are
     currently attempting authentication and the limits configured by
     MaxStartups.

 -- Colin Watson <cjwatson@debian.org>  Fri, 21 Feb 2020 16:36:37 +0000

openssh (1:8.1p1-1) unstable; urgency=medium

  OpenSSH 8.1 includes a number of changes that may affect existing
  configurations:

   * ssh-keygen(1): when acting as a CA and signing certificates with an RSA
     key, default to using the rsa-sha2-512 signature algorithm.
     Certificates signed by RSA keys will therefore be incompatible with
     OpenSSH versions prior to 7.2 unless the default is overridden (using
     "ssh-keygen -t ssh-rsa -s ...").

 -- Colin Watson <cjwatson@debian.org>  Thu, 10 Oct 2019 10:23:19 +0100

Generated by dwww version 1.16 on Sat Dec 13 16:16:14 CET 2025.