Skip to content
HN On Hacker News ↗

OpenSSH: Release Notes

▲ 132 points • 7 comments • by selckin • 5h ago • HN discussion ↗

Pangram verdict · v3.3

We believe that this entire text is human-written.

0 %

AI likelihood · overall

Human
100% human-written 0% AI-generated
SEGMENTS · HUMAN 1 of 1
SEGMENTS · AI 0 of 1
WORD COUNT 1,491
PEAK AI % 0% · §1
Analyzed
Nov 5
backend: pangram/v3.3
Segments scanned
1 windows
avg 1491 words each
Distribution
100 / 0%
human / AI fraction
Verdict
Human
Pangram v3.3

Article text · 1,491 words · 1 segments analyzed

Human AI-generated
§1 Human · 0%

OpenSSH 10.6p2 (2026-11-05) Portable OpenSSH 10.6p2 was released on 2026-11-05. It will be available from the mirrors listed at https://www.openssh.com/. OpenSSH is a 100% complete SSH protocol 2.0 implementation and includes sftp client and server support. Recently the OpenSSH team have received a large number of security bug reports, many of which are findings from AI models or made with AI assistance. While many AI reports are determined not to have security impact when considered in the context of a realistic threat model, we very much welcome these reports, especially when combined with human triage, analysis, test-cases and particularly when accompanied by proposed fixes. ** We have seen a number of cases where a security bug identified ** by AI tools is subsequently independently discovered by a ** different researcher. This suggests that adversaries who do not ** report bugs to OSS projects are likely to be able to discover ** these bugs too. Given this, the OpenSSH team will, for now, be ** making more frequent releases to get bugfixes into users' hands ** more quickly rather than batching them until the next planned ** release. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots or donated to the project. More information on donations may be found at: https://www.openssh.com/donations.html Future deprecation notice ------------------------- * scp(1): begin deprecating the -R flag, which is used to perform a remote-to-remote copy by executing scp on a remote host. This option is a fragile optimisation that is difficult to use because it requires credentials on the remote host. It also creates security risks if the shell quoting rules on the remote system where the copy is performed differ from the client's expectations. From OpenSSH 10.6, this option will continue to work but will cause a deprecation warning to be emitted to standard error. In a future release, the option will be ignored and will leave in place the default remote-to-remote copy behaviour (copy via the host running scp). * sshd(8): support for platforms that do not allow file descriptor passing and that also require root privilege for PTY allocation will be removed in a future release. Affected platforms are known to include SCO OpenServer 5 and QNX 6 but may include other similarly old operating systems. This deprecation can be avoided if the user community for these platforms is able to assist us in building alternatives, such as avoiding the need for root in PTY allocation. Changes since OpenSSH 10.6p1 ============================ This release contains a critical security workaround that affects Linux systems that use the musl libc and PAM disabled. This release also includes a number of bugfixes that had already been committed on the portable OpenSSH V_10_6 stable branch. Security ======== * sshd(8): avoid password authentication bypass that is exploitable through sshd(8) that affects some Linux systems when built and run with PAM support disabled. We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there. This bug was reported by Özgün Kültekin of Wakefield (wakefield.co) Bugfixes -------- * sshd(8), ssh(1): enable the post-quantum hybris signature scheme ssh-mldsa44-ed25519 as an allowed CA signature algorithm. * ssh(1), sshd(8): fix <1 second CPU spin if ChannelTimeout was in use. Portability ----------- * sshd(8): fix compilation on (old) platforms that set SKIP_PRIVDROP * ssh(1), sshd(8): fix detection of Azerbaijani locales * sshd(8), ssh-agent(1): fix creation of agent sockets on platforms without the openat(2) syscall. * ssh(1), ssh-add(1), ssh-keygen(1): fix some strange behaviour if SIGINT/SIGQUIT was received while reading a passphrase. * sshd(8): allow restart_syscall(2) in seccomp sandbox; bz4036 Checksums: ========== - SHA1 (openssh-10.6p2.tar.gz) = c91a0b7860c80f29db874044af4d1a6f906231d9 - SHA256 (openssh-10.6p2.tar.gz) = muRIcgkM8vBrPPn/FH5/FvMJZxNAdj7S+ZJIOYrinVs= Please note that the SHA256 signatures are base64 encoded and not hexadecimal (which is the default for most checksum tools). The PGP key used to sign the releases is available from the mirror sites: https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/RELEASE_KEY.asc Reporting Bugs: =============== - Please read https://www.openssh.com/report.html Security bugs should be reported directly to openssh@openssh.com OpenSSH 10.6/10.6p1 (2026-10-06) OpenSSH 10.6 was released on 2026-10-06. It is available from the mirrors listed at https://www.openssh.com/. OpenSSH is a 100% complete SSH protocol 2.0 implementation and includes sftp client and server support. Recently the OpenSSH team have received a large number of security bug reports, many of which are findings from AI models or made with AI assistance. While many AI reports are determined not to have security impact when considered in the context of a realistic threat model, we very much welcome these reports, especially when combined with human triage, analysis, test-cases and particularly when accompanied by proposed fixes. ** We have seen a number of cases where a security bug identified ** by AI tools is subsequently independently discovered by a ** different researcher. This suggests that adversaries who do not ** report bugs to OSS projects are likely to be able to discover ** these bugs too. Given this, the OpenSSH team will, for now, be ** making more frequent releases to get bugfixes into users' hands ** more quickly rather than batching them until the next planned ** release. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots or donated to the project. More information on donations may be found at: https://www.openssh.com/donations.html Future deprecation notice ------------------------- * scp(1): begin deprecating the -R flag, which is used to perform a remote-to-remote copy by executing scp on a remote host. This option is a fragile optimisation that is difficult to use because it requires credentials on the remote host. It also creates security risks if the shell quoting rules on the remote system where the copy is performed differ from the client's expectations. From OpenSSH 10.6, this option will continue to work but will cause a deprecation warning to be emitted to standard error. In a future release, the option will be ignored and will leave in place the default remote-to-remote copy behaviour (copy via the host running scp). * sshd(8): support for platforms that do not allow file descriptor passing and that also require root privilege for PTY allocation will be removed in a future release. Affected platforms are known to include SCO OpenServer 5 and QNX 6 but may include other similarly old operating systems. This deprecation can be avoided if the user community for these platforms is able to assist us in building alternatives, such as avoiding the need for root in PTY allocation. Potentially-incompatible changes -------------------------------- * ssh(1), sshd(8): compression will be less effective as a result of the change noted below in the "Security" section * ssh(1): destination usernames entered on the commandline are now more strictly checked and will refuse usernames that include backslash and dollar symbols. Usernames that are specified by the "User" directive in configuration files are not subject to these restrictions. The motivation for this change is mentioned below in the "Security" section. * sshd(8): on platforms that do not support file descriptor passing and that require root for PTY allocation, the GatewayPorts and StreamLocalForwarding options are forcibly disabled. The motivation for this change is discussed below in the "Security" section. Changes since OpenSSH 10.5 ========================== This release contains a number of security fixes, several new features and some small bugfixes. Security ======== * sftp(1): more strictly validate paths returned from the server to avoid some cases where a server could return paths that could manipulate a recursive copy operation into writing outside its target directory. Report and patch from Junghoon Cho. * sshd(8): when GSSAPIAuthentication is in use, only store GSSAPI credentials when authentication has succeeded. Avoids a situation where credentials from a failed GSSAPIAuthentication attempt may persist and be made inappropriately available if another authentication subsequently succeeds. Issue report and patch from Moritz Theile. * sshd(8): reset GSSAPIAuthentication before authentication, avoiding state from one authentication attempt being confused with that of a later attempt. Report and feedback from Moritz Theile. * sshd(8), ssh(1): disable LZ77 dictionary coder to mitigate the side-channel leaks described in "Crossing the Streams: SSH Plaintext Recovery via a Common Compression Context in Multiplexed Channels" by Fabian Bäumer and Marcus Brinkmann, preprint https://arxiv.org/abs/2609.07709 (2026) A chosen-plaintext attack method exists which makes use of dictionary-based compression to recover secrets from one channel by interacting with the SSH session's shared compression dictionary through another channel. Attacker-controlled input can recognizably reflect into the total length of transmitted ciphertexts by virtue of LZ77 replacing repeated strings with back-references into the SSH session's encoder search buffer, which is shared across all channels. For this reason, the documentation already recommended against enabling compression for connections that share trusted and untrusted traffic. This change will reduce the effectiveness of the Compression option. Users are encouraged to use application-level compression over the SSH protocol where possible, as this will typically be more effective and will be