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>.

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.

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 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 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.

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 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. Ways of solving this problem are being investigated, since
the SSH 1 protocol is not dead yet.