Debian Patches

Status for openssh/1:10.0p1-7+deb13u4

Patch Description Author Forwarded Bugs Origin Last update
gssapi.patch GSSAPI key exchange support
This patch has been rejected upstream: "None of the OpenSSH developers are
in favour of adding this, and this situation has not changed for several
years. This is not a slight on Simon's patch, which is of fine quality, but
just that a) we don't trust GSSAPI implementations that much and b) we don't
like adding new KEX since they are pre-auth attack surface. This one is
particularly scary, since it requires hooks out to typically root-owned
system resources."

However, quite a lot of people rely on this in Debian, and it's better to
have it merged into the main openssh package rather than having separate
-krb5 packages (as we used to have). It seems to have a generally good
security history.		 Jakub Jelen <jjelen@redhat.com> yes upstream other, https://github.com/openssh-gsskex/openssh-gsskex/pull/23 2014-02-09
restore-tcp-wrappers.patch Restore TCP wrappers support
Support for TCP wrappers was dropped in OpenSSH 6.7. See this message
and thread:

https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-April/032497.html

It is true that this reduces preauth attack surface in sshd. On the
other hand, this support seems to be quite widely used, and abruptly
dropping it (from the perspective of users who don't read
openssh-unix-dev) could easily cause more serious problems in practice.

It's not entirely clear what the right long-term answer for Debian is,
but it at least probably doesn't involve dropping this feature shortly
before a freeze.		 Colin Watson <cjwatson@debian.org> not-needed 2024-08-02
selinux-role.patch Handle SELinux authorisation roles
Rejected upstream due to discomfort with magic usernames; a better approach
will need an SSH protocol change. In the meantime, this came from Debian's
SELinux maintainer, so we'll keep it until we have something better.		 Manoj Srivastava <srivasta@debian.org> yes debian upstream 2024-07-03
ssh-vulnkey-compat.patch Accept obsolete ssh-vulnkey configuration options
These options were used as part of Debian's response to CVE-2008-0166.
Nearly six years later, we no longer need to continue carrying the bulk
of that patch, but we do need to avoid failing when the associated
configuration options are still present.		 Colin Watson <cjwatson@ubuntu.com> no 2014-02-09
keepalive-extensions.patch Various keepalive extensions
Add compatibility aliases for ProtocolKeepAlives and SetupTimeOut, supported
in previous versions of Debian's OpenSSH package but since superseded by
ServerAliveInterval. (We're probably stuck with this bit for
compatibility.)

In batch mode, default ServerAliveInterval to five minutes.

Adjust documentation to match and to give some more advice on use of
keepalives.		 Colin Watson <cjwatson@debian.org> no 2025-04-10
syslog-level-silent.patch "LogLevel SILENT" compatibility
"LogLevel SILENT" (-qq) was introduced in Debian openssh 1:3.0.1p1-1 to
match the behaviour of non-free SSH, in which -q does not suppress fatal
errors. However, this was unintentionally broken in 1:4.6p1-2 and nobody
complained, so we've dropped most of it. The parts that remain are basic
configuration file compatibility, and an adjustment to "Pseudo-terminal will
not be allocated ..." which should be split out into a separate patch.		 Colin Watson <cjwatson@debian.org> no 2013-09-14
user-group-modes.patch Allow harmless group-writability
Allow secure files (~/.ssh/config, ~/.ssh/authorized_keys, etc.) to be
group-writable, provided that the group in question contains only the file's
owner. Rejected upstream for IMO incorrect reasons (e.g. a misunderstanding
about the contents of gr->gr_mem). Given that per-user groups and umask 002
are the default setup in Debian (for good reasons - this makes operating in
setgid directories with other groups much easier), we need to permit this by
default.		 Colin Watson <cjwatson@debian.org> yes debian upstream 2022-02-23
scp-quoting.patch Adjust scp quoting in verbose mode
Tweak scp's reporting of filenames in verbose mode to be a bit less
confusing with spaces.

This should be revised to mimic real shell quoting.		 Nicolas Valcárcel <nvalcarcel@ubuntu.com> no 2010-02-27
shell-path.patch Look for $SHELL on the path for ProxyCommand/LocalCommand
There's some debate on the upstream bug about whether POSIX requires this.
I (Colin Watson) agree with Vincent and think it does.		 Colin Watson <cjwatson@debian.org> yes debian upstream 2020-02-21
dnssec-sshfp.patch Force use of DNSSEC even if "options edns0" isn't in resolv.conf
This allows SSHFP DNS records to be verified if glibc 2.11 is installed.		 Colin Watson <cjwatson@debian.org> invalid debian upstream vendor, https://cvs.fedoraproject.org/viewvc/F-12/openssh/openssh-5.2p1-edns.patch?revision=1.1&view=markup 2023-06-19
mention-ssh-keygen-on-keychange.patch Mention ssh-keygen in ssh fingerprint changed warning Chris Lamb <lamby@debian.org> yes upstream 2023-12-11
package-versioning.patch Include the Debian version in our identification
This makes it easier to audit networks for versions patched against security
vulnerabilities. It has little detrimental effect, as attackers will
generally just try attacks rather than bothering to scan for
vulnerable-looking version strings. (However, see debian-banner.patch.)		 Matthew Vernon <matthew@debian.org> not-needed 2025-02-18
debian-banner.patch Add DebianBanner server configuration option
Setting this to "no" causes sshd to omit the Debian revision from its
initial protocol handshake, for those scared by package-versioning.patch.		 Kees Cook <kees@debian.org> not-needed debian 2025-04-11
authorized-keys-man-symlink.patch Install authorized_keys(5) as a symlink to sshd(8) Tomas Pospisek <tpo_deb@sourcepole.ch> yes debian upstream 2013-09-14
openbsd-docs.patch Adjust various OpenBSD-specific references in manual pages
No single bug reference for this patch, but history includes:
https://bugs.debian.org/154434 (login.conf(5))
https://bugs.debian.org/513417 (/etc/rc)
https://bugs.debian.org/998069, https://bugs.debian.org/1095686 (rdomain(4))		 Colin Watson <cjwatson@debian.org> not-needed 2025-04-15
ssh-argv0.patch ssh(1): Refer to ssh-argv0(1)
Old versions of OpenSSH (up to 2.5 or thereabouts) allowed creating symlinks
to ssh with the name of the host you want to connect to. Debian ships an
ssh-argv0 script restoring this feature; this patch refers to its manual
page from ssh(1).		 Colin Watson <cjwatson@debian.org> not-needed debian 2013-09-14
doc-hash-tab-completion.patch Document that HashKnownHosts may break tab-completion Colin Watson <cjwatson@debian.org> yes debian upstream 2021-11-05
ssh-agent-setgid.patch Document consequences of ssh-agent being setgid in ssh-agent(1) Colin Watson <cjwatson@debian.org> no debian 2020-02-21
no-openssl-version-status.patch Don't check the status field of the OpenSSL version
There is no reason to check the version of OpenSSL (in Debian). If it's
not compatible the soname will change. OpenSSH seems to want to do a
check for the soname based on the version number, but wants to keep the
status of the release the same. Remove that check on the status since
it doesn't tell you anything about how compatible that version is.		 Colin Watson <cjwatson@debian.org> not-needed debian 2023-09-02
gnome-ssh-askpass2-icon.patch Give the ssh-askpass-gnome window a default icon Vincent Untz <vuntz@ubuntu.com> no 2010-02-28
debian-config.patch Various Debian-specific configuration changes
fewer problems with existing setups (http://bugs.debian.org/237021).

(http://bugs.debian.org/264024).

worms.



PrintMotd.







Document all of this.		 Luca Boccassi <bluca@debian.org> not-needed 2025-04-11
restore-authorized_keys2.patch Restore reading authorized_keys2 by default
Upstream seems to intend to gradually phase this out, so don't assume
that this will remain the default forever. However, we were late in
adopting the upstream sshd_config changes, so it makes sense to extend
the grace period.		 Colin Watson <cjwatson@debian.org> not-needed debian 2017-03-05
systemd-socket-activation.patch Support systemd socket activation
Unlike inetd socket activation, with systemd socket activation the
supervisor passes the listened-on socket to the child process and lets
the child process handle the accept(). This lets us do delayed start
of the sshd daemon without becoming incompatible with config options
like ClientAliveCountMax.		 Colin Watson <cjwatson@debian.org> no 2025-04-11
skip-utimensat-test-on-zfs.patch Skip utimensat test on ZFS
On ZFS (which may be used by e.g. `autopkgtest-virt-incus`), `utimensat`
seems to leave the access time set to 0. It's not clear why.		 Colin Watson <cjwatson@debian.org> no 2024-03-11
regress-conch-dev-zero.patch regress: Redirect conch stdin from /dev/zero
This is more convenient than requiring a controlling terminal.		 Colin Watson <cjwatson@debian.org> yes 2024-03-31
configure-cache-vars.patch Add Autoconf cache variables for OSSH_CHECK_*FLAG_*
This allows overriding them on configure's command line in case the
automatic checks go wrong somehow. bz#3673		 Colin Watson <cjwatson@debian.org> yes 2024-04-03
pam-avoid-unknown-host.patch Only set PAM_RHOST if the remote host is not "UNKNOWN"
When using sshd's -i option with stdio that is not a AF_INET/AF_INET6
socket, auth_get_canonical_hostname() returns "UNKNOWN" which is then
set as the value of PAM_RHOST, causing pam to try to do a reverse DNS
query of "UNKNOWN", which times out multiple times, causing a
substantial slowdown when logging in.

To fix this, let's only set PAM_RHOST if the hostname is not "UNKNOWN".		 Daan De Meyer <daan.j.demeyer@gmail.com> no 2024-04-03
CVE-2025-61984.patch upstream: Improve rules for %-expansion of username.
Usernames passed on the commandline will no longer be subject to
% expansion. Some tools invoke ssh with connection information
(i.e. usernames and host names) supplied from untrusted sources.
These may contain % expansion sequences which could yield
unexpected results.

Since openssh-9.6, all usernames have been subject to validity
checking. This change tightens the validity checks by refusing
usernames that include control characters (again, these can cause
surprises when supplied adversarially).

This change also relaxes the validity checks in one small way:
usernames supplied via the configuration file as literals (i.e.
include no % expansion characters) are not subject to these
validity checks. This allows usernames that contain arbitrary
characters to be used, but only via configuration files. This
is done on the basis that ssh's configuration is trusted.

Pointed out by David Leadbeater, ok deraadt@		 "djm@openbsd.org" <djm@openbsd.org> no debian upstream, https://anongit.mindrot.org/openssh.git/commit/?id=35d5917652106aede47621bb3f64044604164043 2026-01-08
CVE-2025-61985.patch upstream: don't allow \0 characters in url-encoded strings.
Suggested by David Leadbeater, ok deraadt@		 "djm@openbsd.org" <djm@openbsd.org> no debian upstream, https://anongit.mindrot.org/openssh.git/commit/?id=43b3bff47bb029f2299bacb6a36057981b39fdb0 2026-01-08
CVE-2025-61984-tests.patch upstream: repair test after changes to percent expansion of usernames
on the commandline.

Test more cases that should/shouldn't expand and lightly test
username validity checks.		 "djm@openbsd.org" <djm@openbsd.org> no debian upstream, https://anongit.mindrot.org/openssh.git/commit/?id=f64701ca25795548a61614d0b13391d6dfa7f38c 2026-01-08
fix-max-startups-tracking.patch upstream: Fix mistracking of MaxStartups process exits in some
situations. At worst, this can cause all MaxStartups slots to fill and sshd
to refuse new connections.

Diagnosis by xnor; ok dtucker@		 "djm@openbsd.org" <djm@openbsd.org> no debian upstream, https://anongit.mindrot.org/openssh.git/commit/?id=eddd1d2daa64a6ab1a915ca88436fa41aede44d4 2025-08-08
CVE-2026-35388.patch upstream: add missing askpass check when using
ControlMaster=ask/autoask and "ssh -O proxy ..."; reported by Michalis
Vasileiadis		 "djm@openbsd.org" <djm@openbsd.org> no debian upstream, https://anongit.mindrot.org/openssh.git/commit/?id=c805b97b67c774e0bf922ffb29dfbcda9d7b5add 2026-05-01
CVE-2026-35385.patch upstream: when downloading files as root in legacy (-O) mode and
without the -p (preserve modes) flag set, clear setuid/setgid bits from
downloaded files as one might expect.

AFAIK this bug dates back to the original Berkeley rcp program.

Reported by Christos Papakonstantinou of Cantina and Spearbit.		 "djm@openbsd.org" <djm@openbsd.org> no debian upstream, https://anongit.mindrot.org/openssh.git/commit/?id=487e8ac146f7d6616f65c125d5edb210519b833a 2026-05-01
CVE-2026-35387.patch upstream: correctly match ECDSA signature algorithms against
algorithm allowlists: HostKeyAlgorithms, PubkeyAcceptedAlgorithms and
HostbasedAcceptedAlgorithms.

Previously, if any ECDSA type (say "ecdsa-sha2-nistp521") was
present in one of these lists, then all ECDSA algorithms would
be permitted.

Reported by Christos Papakonstantinou of Cantina and Spearbit.


[cjwatson: Committed upstream together with apparently-unrelated changes
for CVE-2026-35414. I've split them into separate patches for clarity.]		 "djm@openbsd.org" <djm@openbsd.org> no debian backport, https://anongit.mindrot.org/openssh.git/commit/?id=fd1c7e131f331942d20f42f31e79912d570081fa 2026-05-01
CVE-2026-35414.patch sshd(8): fix inappropriate matching of authorized_keys principals
When matching an authorized_keys principals="" option against a list of
principals in a certificate, an incorrect algorithm was used that could
allow inappropriate matching in cases where a principal name in the
certificate contains a comma character. Exploitation of the condition
requires an authorized_keys principals="" option that lists more than
one principal *and* a CA that will issue a certificate that encodes more
than one of these principal names separated by a comma (typical CAs
strongly constrain which principal names they will place in a
certificate). This condition only applies to user- trusted CA keys in
authorized_keys, the main certificate authentication path
(TrustedUserCAKeys/AuthorizedPrincipalsFile) is not affected.

Reported by Vladimir Tokarev.


[cjwatson: Committed upstream together with apparently-unrelated changes
for CVE-2026-35387. I've split them into separate patches for clarity.]		 "djm@openbsd.org" <djm@openbsd.org> no debian backport, https://anongit.mindrot.org/openssh.git/commit/?id=fd1c7e131f331942d20f42f31e79912d570081fa 2026-05-01
CVE-2026-35386-1.patch upstream: apply the same validity rules to usernames and hostnames
set for ProxyJump/-J on the commandline as we do for destination user/host
names.

Specifically, they are no longer allowed to contain most characters
that have special meaning for common shells. Special characters are
still allowed in ProxyJump commands that are specified in the config
files.

This _reduces_ the chance that shell characters from a hostile -J
option from ending up in a shell execution context.

Don't pass untrusted stuff to the ssh commandline, it's not intended
to be a security boundary. We try to make it safe where we can, but
we can't make guarantees, because we can't know the parsing rules
and special characters for all the shells in the world, nor can we
know what the user does with this data in their ssh_config wrt
percent expansion, LocalCommand, match exec, etc.

While I'm in there, make ProxyJump and ProxyCommand first-match-wins
between each other.

reported by rabbit; ok dtucker@		 "djm@openbsd.org" <djm@openbsd.org> no debian upstream, https://anongit.mindrot.org/openssh.git/commit/?id=0a0ef4515361143cad21afa072319823854c1cf6 2026-05-01
CVE-2026-35386-2.patch upstream: move username validity check for usernames specified on
the commandline to earlier in main(), specifically before some contexts where
a username with shell characters might be expanded by a %u directive in
ssh_config.

We continue to recommend against using untrusted input on
the SSH commandline. Mitigations like this are not 100%
guarantees of safety because we can't control every
combination of user shell and configuration where they are
used.

Reported by Florian Kohnhäuser		 "djm@openbsd.org" <djm@openbsd.org> no debian upstream, https://anongit.mindrot.org/openssh.git/commit/?id=76685c9b09a66435cd2ad8373246adf1c53976d3 2026-05-01
CVE-2026-35386-3.patch upstream: adapt to username validity check change "djm@openbsd.org" <djm@openbsd.org> no debian upstream, https://anongit.mindrot.org/openssh.git/commit/?id=5aa09926fbf050d484a79717fadec8360c5c5645 2026-05-01
ipqos-interactive-ef.patch upstream: Set default IPQoS for interactive sessions to Expedited
Forwarding (EF)

Marking interactive session data with DSCP value EF (RFC3246, RFC3247)
helps inform the network on relative priority compared to other traffic.
This is especially useful for differentiated treatment over wireless media.

Following the reconciled IETF Diffserv to IEEE 802.11 mappings (RFC 8325),
traffic marked with DSCP value EF maps to User Priority 6 in QoS Control,
in turn mapping to the high priority WMM AC_VO access category.

OK djm@		 "job@openbsd.org" <job@openbsd.org> no upstream, https://anongit.mindrot.org/openssh.git/commit/?id=65909fa114e7dd7511800db2b7bacb8774afe887 2026-05-03
ipqos-deprecate-tos-keywords.patch upstream: Deprecate support for IPv4 type-of-service (TOS) IPQoS
keywords

Type of Service (ToS) was deprecated in the late nineties and replaced
with the Differentiated Services architecture. Diffserv has significant
advantages for operators because this mechanism offers more granularity.

OpenSSH switched its default IPQoS from ToS to DSCP values in 2018.

IPQoS configurations with 'lowdelay', 'reliability', or 'throughput' will be
ignored and instead the system default QoS settings apply. Additionally, a
debug message is logged about the deprecation with a suggestion to use DSCP.

with/OK deraadt@ sthen@ djm@		 "job@openbsd.org" <job@openbsd.org> no upstream, https://anongit.mindrot.org/openssh.git/commit/?id=ec3465f59c651405e395092f3ad606f8992328d8 2026-05-03
ipqos-set-at-runtime.patch upstream: Make ssh(1) and sshd(8) set IP QoS (aka IP_TOS, IPV6_TCLASS)

continually at runtime based on what sessions/channels are open.

Previously, ssh(1) and sshd(8) would pick a QoS value when they
were started and use it for the whole connection. This could
produce suboptimal choices for the QoS value, e.g. for multiplexed
sessions that started interactive but picked up a sftp client,
or sessions that moved large amounts of data via port forwarding.

Now the QoS value will change to the non-interactive IPQoS whenever
a "non-interactive" channel is open; basically any channel that lacks
a tty other than agent forwarding.

This is important now that the default interactive IPQoS is EF
(Expedited Forwarding), as many networks are configured to allow
only relatively small amounts of traffic of this class and they will
aggressively deprioritise the entire connection if this is exceeded.

NB. because ssh(1) and sshd(8) now change IP_TOS/IPV6_TCLASS
continually via setsockopt(), this commit requires a recent pledge(2)
change that landed recently in the OpenBSD kernel. Please ensure
you have updated to a kernel from within the last two weeks before
updating OpenSSH.

with job@ deraadt@		 "djm@openbsd.org" <djm@openbsd.org> no backport, https://anongit.mindrot.org/openssh.git/commit/?id=289239046b2c4b0076c14394ae9703a879e78706 2026-05-03
ipqos-set-extended-type.patch upstream: correctly set extended type for client-side channels.
Fixes interactive vs bulk IPQoS for client->server traffic. ok job@		 "djm@openbsd.org" <djm@openbsd.org> no upstream, https://anongit.mindrot.org/openssh.git/commit/?id=45b30e0a5439a02417a4fe982a4b16a9c126ba6b 2026-05-03
avoid-channel-isatty-overloading.patch upstream: don't reuse c->isatty for signalling that the remote channel

has a tty attached as this causes side effects, e.g. in channel_handle_rfd().
bz3872

ok markus@		 "djm@openbsd.org" <djm@openbsd.org> no debian upstream, https://anongit.mindrot.org/openssh.git/commit/?id=979cbc2c1e0c9cd2f60d45d8d1da69519ec425cf 2026-05-06

All known versions for source package 'openssh'

Links