OpenSSH Security

OpenSSH is developed with the same rigorous security process that the OpenBSD group is famous for. If you wish to report a security issue in OpenSSH, please contact the private developers list <openssh@openssh.com>.

For more information, see the OpenBSD security page.

• July 1, 2024
  sshd(8) in Portable OpenSSH versions 8.5p1 to 9.7p1 (inclusive).
  Race condition resulting in potential remote code execution.
  A race condition in sshd(8) could allow remote code execution as root on non-OpenBSD systems. This attack could be prevented by disabling the login grace timeout (LoginGraceTime=0 in sshd_config) though this makes denial-of service against sshd(8) considerably easier.
  For more information, please refer to the release notes and the report from the Qualys Security Advisory Team who discovered the bug.

• July 1, 2024
  ssh(1) in OpenSSH versions 9.5p1 to 9.7p1 (inclusive).
  Logic error in ObscureKeystrokeTiming option.
  A logic error in the implementation of the ssh(1) ObscureKeystrokeTiming option rendered the feature ineffective and additionally exposed limited keystroke timing information when terminal echo was disabled, e.g. while entering passwords to su(8) or sudo(8). This condition could be avoided for affected versions by disabling the feature using ObscureKeystrokeTiming=no.
  For more information, please refer to the release notes.

• December 18, 2023
  ssh(1), sshd(8) in OpenSSH prior to version 9.6.
  Weakness in initial key exchange ("Terrapin Attack")
  A weakness in the initial SSH protocol key exchange allows an on-path attacker to delete a number of consecutive messages from the early encrypted protocol without detection. While cryptographically novel, there is no discernable impact on the integrity of SSH traffic beyond giving the attacker the ability to delete the message that enables some features related to keystroke timing obfuscation.
  This attack is prevented by a new protocol extension in OpenSSH 9.6.
  For more information, please refer to the release notes.

• December 18, 2023
  ssh-agent(1) in OpenSSH between 8.9 and 9.5 (inclusive)
  Incomplete application of destination constraints to smartcard keys.
  Destination constraints added when loading PKCS#11 keys from a token were being applied to only the first key returned from the token.
  This bug is corrected in OpenSSH 9.6.
  For more information, please refer to the release notes.

• July 19, 2023
  ssh-agent(1) in OpenSSH between and 5.5 and 9.3p1 (inclusive) remote code execution relating to PKCS#11 providers
  The PKCS#11 support ssh-agent(1) could be abused to achieve remote code execution via a forwarded agent socket if the following conditions are met:

  • Exploitation requires the presence of specific libraries on the victim system.
  • Remote exploitation requires that the agent was forwarded to an attacker-controlled system.
  Exploitation can also be prevented by starting ssh-agent(1) with an empty PKCS#11/FIDO allowlist (ssh-agent -P '') or by configuring an allowlist that contains only specific provider libraries.
  This vulnerability was discovered and demonstrated to be exploitable by the Qualys Security Advisory team. This vulnerability has been assigned CVE-2023-38408.
  This bug is corrected in OpenSSH 9.3p2. For OpenBSD, an errata patch exists to fix this problem.
  For more information, please refer to the release notes.

• March 15, 2023
  ssh-add(1) in OpenSSH between and 8.9 and 9.2 (inclusive).
  ssh-add(1) did not apply destination constraints to smartcard keys.
  When adding smartcard keys to ssh-agent(1) with the per-hop destination constraints (ssh-add -h ...), a logic error prevented the constraints from being communicated to the agent. This resulted in the keys being added without constraints. The common cases of non-smartcard keys and keys without destination constraints are unaffected.
  This bug is corrected in OpenSSH 9.3.
  For more information, please refer to the release notes.

• February 2, 2023
  ssh(1) in OpenSSH between and 8.7 and 9.1 (inclusive).
  ssh(1) failed to correctly process PermitRemoteOpen options.
  The PermitRemoteOpen option would ignore its first argument unless it was one of the special keywords "any" or "none", causing the permission list to fail open if only one permission was specified.
  This bug is corrected in OpenSSH 9.2.
  For more information, please refer to the release notes.

• February 2, 2023
  ssh(1) in OpenSSH between and 6.5 and 9.1 (inclusive).
  ssh(1) failed to check DNS names returned from libc for validity.
  If the CanonicalizeHostname and CanonicalizePermittedCNAMEs options were enabled, and the system/libc resolver did not check that names in DNS responses were valid, then use of these options could allow an attacker with control of DNS to include invalid characters (possibly including wildcards) in names added to known_hosts files when they were updated. These names would still have to match the CanonicalizePermittedCNAMEs allow-list, so practical exploitation appears unlikely.
  This bug is corrected in OpenSSH 9.2.
  For more information, please refer to the release notes.

• February 2, 2023
  sshd in OpenSSH between and 9.1 (only).
  Double-free memory fault in pre-authentication sshd process.
  sshd(8) contained a network-reachable pre-authentication double-free memory fault introduced in OpenSSH 9.1. This is not believed to be exploitable, and it occurs in the unprivileged pre-auth process that is subject to chroot(2) and is further sandboxed on most major platforms.
  This bug is corrected in OpenSSH 9.2.
  For more information, please refer to the release notes.

• September 26, 2021
  sshd in OpenSSH between 6.2 and 8.7 (inclusive).
  sshd(8) failed to correctly initialise supplemental groups when executing an AuthorizedKeysCommand or AuthorizedPrincipalsCommand, where a AuthorizedKeysCommandUser or AuthorizedPrincipalsCommandUser directive was been set to run the command as a non-root user. Instead these commands would inherit the groups that sshd(8) was started with.
  Depending on system configuration, inherited groups may allow the helper programs to gain unintended privilege.
  Neither AuthorizedKeysCommand nor AuthorizedPrincipalsCommand are enabled by default in sshd_config(5).
  This bug is corrected in OpenSSH 8.8
  For more information, please refer to the release notes.

• March 3, 2021
  ssh-agent in OpenSSH between 8.2 and 8.4 (inclusive).
  Double-free memory corruption. Mitigated by socket peer user identity checking and double-free protection in malloc(3). This bug is corrected in OpenSSH 8.5 For more information, please refer to the release notes.

• October 3, 2017
  All version of OpenSSH prior to 7.6 supporting read-only mode in sftp-server (introduced in 5.5). Incorrect open(2) flags in sftp-server permitted creation of zero-length files when the server was running in read-only mode (invoked using the -R command-line flag).
  This bug is corrected in OpenSSH 7.6. For more information, please refer to the release notes.

• March 9, 2016
  All versions of OpenSSH prior to 7.2p2 with X11Forwarding enabled. Missing sanitisation of untrusted input allows an authenticated user who is able to request X11 forwarding to inject commands to xauth(1).

  Mitigate by setting X11Forwarding=no in sshd_config, or on the commandline. This is the default, but some vendors enable the feature.

  For more information see the advisory.
  This bug is corrected in OpenSSH 7.2p2 and in OpenBSD's stable branch. For more information, please refer to the release notes.

• January 14, 2016
  OpenSSH clients between versions 5.4 and 7.1 are vulnerable to information disclosure that may allow a malicious server to retrieve information including under some circumstances, user's private keys. This may be mitigated by adding the undocumented config option UseRoaming no to ssh_config.
  For more information see CVE-2016-0777 and CVE-2016-0778.
  This bug is corrected in OpenSSH 7.1p2 and in OpenBSD's stable branch. For more information, please refer to the release notes.

• August 21, 2015
  OpenSSH 7.0 contained a logic error in PermitRootLogin= prohibit-password/without-password that could, depending on compile-time configuration, permit password authentication to root while preventing other forms of authentication.
  This bug is corrected in OpenSSH 7.1. For more information, please refer to the release notes

• August 11, 2015
  OpenSSH 6.7 through 6.9 assign weak permissions to TTY devices.
  Keyboard-interactive authentication in OpenSSH prior to 7.0 may allow circumvention of MaxAuthTries.
  These bugs are corrected in OpenSSH 7.0. For more information, please refer to the release notes

• June 30, 2015
  OpenSSH prior to 6.9 suffered from a race condition that could allow non-trusted X11 forwarding sessions to be treated as trusted. For more information, please refer to the release notes

• November 8, 2013:
  OpenSSH versions 6.2 and 6.3 are vulnerable to the memory corruption problem described in the gcmrekey.adv advisory and the OpenSSH 6.4 release notes.

• February 2, 2011:
  Portable OpenSSH prior to version 5.8p2 is vulnerable to the local host key theft attack described in portable-keysign-rand-helper.adv advisory and the OpenSSH 5.8p2 release notes.

• January 24, 2011:
  OpenSSH versions 5.6 and 5.7 are vulnerable to a potential leak of private key data described in the legacy-cert.adv advisory and the OpenSSH 5.8 release notes.

• February 23, 2009:
  OpenSSH prior to version 5.2 is vulnerable to the protocol weakness described in CPNI-957037 "Plaintext Recovery Attack Against SSH". However, based on the limited information available it appears that this described attack is infeasible in most circumstances. For more information please refer to the cbc.adv advisory and the OpenSSH 5.2 release notes.

• July 22, 2008:
  Portable OpenSSH 5.1 and newer are not vulnerable to the X11UseLocalhost=no hijacking attack on HP/UX (and possibly other systems) described in the OpenSSH 5.1 release notes.

• April 3, 2008:
  OpenSSH 5.0 and newer are not vulnerable to the X11 hijacking attack described in CVE-2008-1483 and the OpenSSH 5.0 release notes.

• March 31, 2008:
  OpenSSH 4.9 and newer do not execute ~/.ssh/rc for sessions whose command has been overridden with a sshd_config(5) ForceCommand directive. This was a documented, but unsafe behaviour (described in OpenSSH 4.9 release notes).

• September 5, 2007:
  OpenSSH 4.7 and newer do not fall back to creating trusted X11 authentication cookies when untrusted cookie generation fails (e.g. due to deliberate resource exhaustion), as described in the OpenSSH 4.7 release notes.

• November 7, 2006:
  OpenSSH 4.5 and newer fix a weakness in the privilege separation monitor that could be used to spoof successful authentication (described in the OpenSSH 4.5 release notes). Note that exploitation of this vulnerability would require an attacker to have already subverted the network-facing sshd(8) process, and no vulnerabilities permitting this are known.

• September 27, 2006:
  OpenSSH 4.4 and newer is not vulnerable to the unsafe signal handler vulnerability described in the OpenSSH 4.4 release notes.

• September 27, 2006:
  OpenSSH 4.4 and newer is not vulnerable to the SSH protocol 1 denial of service attack described in the OpenSSH 4.4 release notes.

• February 1, 2006:
  OpenSSH 4.3 and newer are not vulnerable to shell metacharacter expansion in scp(1) local-local and remote-remote copies (CVE-2006-0225), as described in the OpenSSH 4.3 release notes.

• September 1, 2005:
  OpenSSH 4.2 and newer does not allow delegation of GSSAPI credentials after authentication using a non-GSSAPI method as described in the OpenSSH 4.2 release notes.

• September 1, 2005:
  OpenSSH 4.2 and newer do not incorrectly activate GatewayPorts for dynamic forwardings (bug introduced in OpenSSH 4.0) as described in the OpenSSH 4.2 release notes.

• September 16, 2003:
  Portable OpenSSH 3.7.1p2 and newer are not vulnerable to "September 23, 2003: Portable OpenSSH Multiple PAM vulnerabilities", OpenSSH Security Advisory. (This issue does not affect OpenBSD versions)

• September 16, 2003:
  OpenSSH 3.7.1 and newer are not vulnerable to "September 16, 2003: OpenSSH Buffer Management bug", OpenSSH Security Advisory and CERT Advisory CA-2003-24.

• August 1, 2002:
  OpenSSH version 3.2.2p1, 3.4p1 and 3.4 were trojaned on the OpenBSD FTP server and potentially propagated via the normal mirroring process to other FTP servers. The code was inserted some time between the 30th and 31th of July. We replaced the trojaned files with their originals at 7AM MDT, August 1st: OpenBSD Advisory.

• June 26, 2002:
  OpenSSH 3.4 and newer are not vulnerable to "June 26, 2002: OpenSSH Remote Challenge Vulnerability", OpenSSH Security Advisory.

• March 29, 2002:
  OpenSSH 3.2.1 and newer are not vulnerable to "April 21, 2002: Buffer overflow in AFS/Kerberos token passing code", OpenSSH Security Advisory: Versions prior to OpenSSH 3.2.1 allow privileged access if AFS/Kerberos token passing is compiled in and enabled (either in the system or in sshd_config).

• March 7, 2002:
  OpenSSH 3.1 and newer are not vulnerable to "March 7, 2002: Off-by-one error in the channel code", OpenSSH Security Advisory.

• November 24, 2001:
  OpenSSH 3.0.2 and newer do not allow users to pass environment variables to login(1) if UseLogin is enabled. The UseLogin option is disabled by default in all OpenSSH releases.

• May 21, 2001:
  OpenSSH 2.9.9 and newer are not vulnerable to "Sep 26, 2001: Weakness in OpenSSH's source IP based access control for SSH protocol v2 public key authentication.", OpenSSH Security Advisory.

• May 21, 2001:
  OpenSSH 2.9.9 and newer do not allow users to delete files named "cookies" if X11 forwarding is enabled. X11 forwarding is disabled by default.

• November 6, 2000:
  OpenSSH 2.3.1, a development snapshot which was never released, was vulnerable to "Feb 8, 2001: Authentication By-Pass Vulnerability in OpenSSH-2.3.1", OpenBSD Security Advisory. In protocol 2, authentication could be bypassed if public key authentication was permitted. This problem does exist only in OpenSSH 2.3.1, a three week internal development release. OpenSSH 2.3.0 and versions newer than 2.3.1 are not vulnerable to this problem.

• November 6, 2000:
  OpenSSH 2.3.0 and newer do not allow malicious servers to access the client's X11 display or ssh-agent. This problem has been fixed in OpenSSH 2.3.0.

• November 6, 2000:
  OpenSSH 2.3.0 and newer are not vulnerable to the "Feb 8, 2001: SSH-1 Daemon CRC32 Compensation Attack Detector Vulnerability", RAZOR Bindview Advisory CAN-2001-0144. A buffer overflow in the CRC32 compensation attack detector can lead to remote root access. This problem has been fixed in OpenSSH 2.3.0. However, versions prior to 2.3.0 are vulnerable.

• September 2, 2000:
  OpenSSH 2.2.0 and newer are not vulnerable to the "Feb 7, 2001: SSH-1 Session Key Recovery Vulnerability", CORE-SDI Advisory CORE-20010116. OpenSSH imposes limits on the connection rate, making the attack unfeasible. Additionally, the Bleichenbacher oracle has been closed completely since January 29, 2001.

• June 8, 2000:
  OpenSSH 2.1.1 and newer do not allow a remote attacker to execute arbitrary commands with the privileges of sshd if UseLogin is enabled by the administrator. UseLogin is disabled by default. This problem has been fixed in OpenSSH 2.1.1.

• OpenSSH was never vulnerable to the "Feb 5, 2001: SSH-1 Brute Force Password Vulnerability", Crimelabs Security Note CLABS200101.

• OpenSSH was not vulnerable to the RC4 cipher password cracking, replay, or modification attacks. At the time that OpenSSH was started, it was already known that SSH 1 used the RC4 stream cipher completely incorrectly, and thus RC4 support was removed.

• OpenSSH was not vulnerable to client forwarding attacks in unencrypted connections, since unencrypted connection support was removed at OpenSSH project start.

• OpenSSH was not vulnerable to IDEA-encryption algorithm attacks on the last packet, since the IDEA algorithm is not supported. The patent status of IDEA makes it unsuitable for inclusion in OpenSSH.

• OpenSSH does not treat localhost as exempt from host key checking, thus making it not vulnerable to the host key authentication bypass attack.

• OpenSSH was not vulnerable to uncontrollable X11 forwarding attacks because X11-forwarding is disabled by default and the user can de-permit it.

• OpenSSH has the SSH 1 protocol deficiency that might make an insertion attack difficult but possible. The CORE-SDI deattack mechanism is used to eliminate the common case. SSH 1 protocol support is disabled by default.