upstream: Check if dbclient supports SHA1 before trying SHA1-based
KEX.
Dropbear 2025.87 removed SHA1 support by default, which means
diffie-hellman-group14-sha1 is not available. Unfortunately there isn't a
flag to query supported KEX, so instead check MACs and if it doesn't have
SHA1 methods, assuming SHA1 based KEXes are likewise not available. Spotted
by anton@.
upstream: Prime caches for DNS names needed for tests.
When running the SSHFP tests, particularly on an ephemeral VM, the first
query or two can fail for some reason, presumably because something isn't
fully initialized or something. To work around this, issue queries for the
names we'll need before we need them.
Darren Tucker [Wed, 26 Feb 2025 07:16:03 +0000 (18:16 +1100)]
Check for le32toh, le64toh, htole64 individually.
It appears that at least some versions of endian.h in glibc do not have
the latter two, so check for and replace each one individually.
bz#3794, ok djm@
upstream: fix regression introduced when I switched the "Match"
criteria tokeniser to a more shell-like one. Apparently the old tokeniser
(accidentally?) allowed "Match criteria=argument" as well as the "Match
criteria argument" syntax that we tested for.
People were using this syntax so this adds back support for
"Match criteria=argument"
upstream: update the Streamlined NTRU Prime code from the "ref"
implementation in SUPERCOP 20201130 to the "compact" implementation in
SUPERCOP 20240808. The new version is substantially faster. Thanks to Daniel
J Bernstein for pointing out the new implementation (and of course for
writing it).
Damien Miller [Mon, 9 Sep 2024 07:30:38 +0000 (17:30 +1000)]
declare defeat trying to detect C89 compilers
I can't find a reliable way to detect the features the ML-KEM code
requires in configure. Give up for now and use VLA support (that we
can detect) as a proxy for "old compiler" and turn off ML-KEM if
it isn't supported.
Damien Miller [Mon, 9 Sep 2024 06:06:21 +0000 (16:06 +1000)]
test for compiler feature needed for ML-KEM
The ML-KEM implementation we uses need the compiler to support
C99-style named struct initialisers (e.g foo = {.bar = 1}). We
still support (barely) building OpenSSH with older compilers, so
add a configure test for this.
upstream: make parsing user@host consistently look for the last '@' in
the string rather than the first. This makes it possible to use usernames
that contain '@' characters.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
upstream: Add experimental support for hybrid post-quantum key exchange
ML-KEM768 with ECDH/X25519 from the Internet-draft:
https://datatracker.ietf.org/doc/html/draft-kampanakis-curdle-ssh-pq-ke-03
This is based on previous patches from markus@ but adapted to use the
final FIPS203 standard ML-KEM using a formally-verified implementation
from libcrux.
Note this key exchange method is still a draft and thus subject to
change. It is therefore disabled by default; set MLKEM=yes to build it.
We're making it available now to make it easy for other SSH
implementations to test against it.
Antonio Larrosa [Fri, 23 Aug 2024 10:21:06 +0000 (12:21 +0200)]
Don't skip audit before exitting cleanup_exit
This fixes an issue where the SSH_CONNECTION_ABANDON event is not
audited because cleanup_exit overrides the regular _exit too soon and
as a result, failed auth attempts are not logged correctly.
The problem was introduced in 81c1099d22b81ebfd20a334ce986c4f753b0db29
where the code from upstream was merged before the audit_event call when
it should have been merged right before the _exit call in order to honor
the comment that just mentions an override of the exit value.
upstream: As defined in the RFC, the SSH protocol has negotiable
compression support (which is requested as the name "zlib"). Compression
starts very early in the session. Relative early in OpenSSH lifetime, privsep
was added to sshd, and this required a shared-memory hack so the two
processes could see what was going on in the dataflow. This shared-memory
hack was soon recognized as a tremendous complexity risk, because it put libz
(which very much trusts it's memory) in a dangerous place, and a new option
("zlib@openssh.com") was added begins compression after authentication (aka
delayed-compression). That change also permitted removal of the
shared-memory hack. Despite removal from the server, the old "zlib" support
remained in the client, to allow negotiation with non-OpenSSH daemons which
lack the delayed-compression option. This commit deletes support for the
older "zlib" option in the client. It reduces our featureset in a small way,
and encourages other servers to move to a better design. The SSH protocol is
different enough that compressed-key-material attacks like BEAST are
unlikely, but who wants to take the chance? We encourage other ssh servers
who care about optional compression support to add delayed-zlib support.
(Some already do "zlib@openssh.com") ok djm markus
Darren Tucker [Thu, 22 Aug 2024 10:36:12 +0000 (20:36 +1000)]
Move rekey test into valgrind-2.
Now that the rekey test has been optimized it's fast enough to not be in
its own valgrind test, so move it into valgrind-2, which is currently
the quickest of the others, bringing all of them to roughly the same
runtime of ~1.1 hours.
upstream: Use curve25519-sha256 kex where possible.
Except where we're explicitly testing a different kex, use
curve25519-sha256 since it's faster than the default and supported even
when configured without OpenSSL. Add a check to ensure that the kex we
intended to test is the one we actually tested. Speeds test up by ~5%.
upstream: Unnest rekey param parsing test and use ssh not sshd.
ssh uses the same parsing code, now has "-G" to dump its config and is
slightly faster to start up. This speeds up the test slightly (~5%) in the
common case but should help more during instrumented tests, eg under
valgrind, where startup costs are magnified.
djm@openbsd.org [Tue, 20 Aug 2024 03:48:30 +0000 (03:48 +0000)]
upstream: place shielded keys (i.e. keys at rest in RAM) into memory
allocated using mmap(3) with MAP_CONCEAL set. This prevents exposure of the
key material in coredumps, etc (this is in addition to other measures we take
in this area).
Philip Hands [Thu, 8 Aug 2024 11:01:47 +0000 (13:01 +0200)]
update copyright notices
Bump the year to 2024, but also reflect the fact that hands.com Ltd. has
been wound up in the UK, and its assets (including this copyright) have
now reverted to its owner, Philip Hands.