signature scheme that combines ML-DSA 44 and Ed25519 using the construction
specified in draft-ietf-lamps-pq-composite-sigs. There's also an early draft
documenting use of the integration of this scheme into SSH as
draft-miller-sshm-mldsa44-ed25519-composite-sigs
This scheme is not enabled by default. To you use, you'll need
to add it to HostKeyAlgorithms, PubkeyAcceptedAlgorithms, etc.
Keys may be generated using "ssh-keygen -t mldsa44-ed25519".
The ML-DSA implementation comes from libcrux. Thanks to
Jonas Schneider-Bensch and Jonathan Protzenko for their work to
make this available.
Consensus is that it's time to get this in to allow people to
experiment with it.
feedback markus@ tb@ logan@ deraadt@
OpenBSD-Commit-ID: 85f2d41e3d3374b4e8c28a45a7c92f153c4489e2
support rekeying. AFAIK this is only an ancient Sun SSH version.
If such an implementation tries to interoperate with OpenSSH, it
will eventually fail when the transport needs rekeying.
This is probably long enough to use it to download a modern SSH
implementation that lacks this problem :)
ok markus@ deraadt@
OpenBSD-Commit-ID: 228a502fee808cf8b7caee23169eb6a1ab1c331a
certificates were originally specified to represent any principal if the
principals list was empty.
This was, in retrospect, a mistake as it created a fail-open
situation if a CA could be convinced to accidentally sign a
certificate with no principals. This actually happened in a 3rd-
party CA product (CVE-2024-7594).
Somewhat fortunately, the main pathway for using certificates in
sshd (TrustedUserCAKeys) never supported empty-principals
certificates, so the blast radius of such mistakes was
substantially reduced.
This change removes this footcannon and requires all certificates
include principals sections. It also fixes interpretation of
wildcard principals, and properly enables them for host
certificates only.
This is a behaviour change that will permanently break uses of
certificates with empty principals sections.
ok markus@
OpenBSD-Commit-ID: 0a901f03c567c100724a492cf91e02939904712e
non-post quantum safe key agreement algorithm.
Controlled via a new WarnWeakCrypto ssh_config option, defaulting
to on. This option might grow additional weak crypto warnings in
the future.
More details at https://openssh.com/pq.html
mostly by deraadt@ feedback dtucker@ ok deraadt@
OpenBSD-Commit-ID: 974ff243a1eccceac6a1a9d8fab3bcc89d74a2a4
HostkeyAlgorithms. Allows HostkeyAlgorithms to disable implicit fallback from
certificate keys to plain keys. ok markus@
OpenBSD-Commit-ID: 364087e4a395ff9b2f42bf3aefdb2090bb23643a
addresses by AddressFamily if one was specified. Fixes the case where, if
CanonicalizeHostname is enabled, ssh may ignore AddressFamily. bz5326; ok
dtucker
OpenBSD-Commit-ID: 6c7d7751f6cd055126b2b268a7b64dcafa447439
We've previously removed a lot of the really old compatibility code,
and with it went the need to include compat.h in most of the files that
have it.
OpenBSD-Commit-ID: 5af8baa194be00a3092d17598e88a5b29f7ea2b4
-oUserKnownHostsFile=none and a hostkey in one of the system known hosts file
changes; ok dtucker@
OpenBSD-Commit-ID: 7ca87614bfc6da491315536a7f2301434a9fe614
going to known_hosts with a more relaxed check for bad characters; previous
commit broke address literals. Reported by/feedback from florian@
OpenBSD-Commit-ID: 10b86dc6a4b206adaa0c11b58b6d5933898d43e0
never write a name with bad characters to a known_hosts file.
reported by David Leadbeater, ok deraadt@
OpenBSD-Commit-ID: ba9b25fa8b5490b49398471e0c9657b0cbc7a5ad
Have ssh-add accept a list of "destination constraints" that allow
restricting where keys may be used in conjunction with a ssh-agent/ssh
that supports session ID/hostkey binding.
Constraints are specified as either "[user@]host-pattern" or
"host-pattern>[user@]host-pattern".
The first form permits a key to be used to authenticate as the
specified user to the specified host.
The second form permits a key that has previously been permitted
for use at a host to be available via a forwarded agent to an
additional host.
For example, constraining a key with "user1@host_a" and
"host_a>host_b". Would permit authentication as "user1" at
"host_a", and allow the key to be available on an agent forwarded
to "host_a" only for authentication to "host_b". The key would not
be visible on agent forwarded to other hosts or usable for
authentication there.
Internally, destination constraints use host keys to identify hosts.
The host patterns are used to obtain lists of host keys for that
destination that are communicated to the agent. The user/hostkeys are
encoded using a new [email protected] key
constraint.
host keys are looked up in the default client user/system known_hosts
files. It is possible to override this set on the command-line.
feedback Jann Horn & markus@
ok markus@
OpenBSD-Commit-ID: ef47fa9ec0e3c2a82e30d37ef616e245df73163e
when it encounters an unquoted comment.
Add some additional utility function for working with argument
vectors, since we'll be switching to using them to parse
ssh/sshd_config shortly.
ok markus@ as part of a larger diff; tested in snaps
OpenBSD-Commit-ID: fd9c108cef2f713f24e3bc5848861d221bb3a1ac
to obtain known_hosts data from a command in addition to the usual files.
The command accepts bunch of %-expansions, including details of the
connection and the offered server host key. Note that the command may
be invoked up to three times per connection (see the manpage for
details).
ok markus@
OpenBSD-Commit-ID: 2433cff4fb323918ae968da6ff38feb99b4d33d0
Add load_hostkeys_file() and hostkeys_foreach_file() that accept a
FILE* argument instead of opening the file directly.
Original load_hostkeys() and hostkeys_foreach() are implemented using
these new interfaces.
Add a u_int note field to the hostkey_entry and hostkey_foreach_line
structs that is passed directly from the load_hostkeys() and
hostkeys_foreach() call. This is a lightweight way to annotate results
between different invocations of load_hostkeys().
ok markus@
OpenBSD-Commit-ID: 6ff6db13ec9ee4edfa658b2c38baad0f505d8c20
TCP connect. The connection phase of the SSH session is time-sensitive (due
to server side login grace periods) and is frequently interactive (e.g.
entering passwords). The ultimate interactive/bulk TOS/DSCP will be set after
authentication completes.
ok dtucker@
OpenBSD-Commit-ID: f31ab10d9233363a6d2c9996007083ba43a093f1
report the type because it is ambiguous as to whether it referred to the
known or new host key. bz3216; ok dtucker@
OpenBSD-Commit-ID: 2d5ce4a83dbcf44e340a572e361decad8aab7bad
find_by_key_ctx struct. Initializing a single member should be enough
(the spec says the remainder should be initialized as per the static
rules) but some GCCs warn on this which prevents us testing with -Werror
on those. ok deraadt@ djm@
OpenBSD-Commit-ID: 687126e60a27d30f02614760ef3c3ae4e8d6af28
any other host names/addresses already associated with the key. E.g.
> The authenticity of host 'test (10.0.0.1)' can't be established.
> ECDSA key fingerprint is SHA256:milU4MODXm8iJQI18wlsbPG7Yup+34fuNNmV08qDnax.
> This host key is known by the following other names/addresses:
> ~/.ssh/known_hosts:1: host.example.org,10.0.0.1
> ~/.ssh/known_hosts:2: [hashed name]
> ~/.ssh/known_hosts:3: [hashed name]
> ~/.ssh/known_hosts:4: host
> ~/.ssh/known_hosts:5: [host]:2222
> Are you sure you want to continue connecting (yes/no/[fingerprint])?
feedback and ok markus@
OpenBSD-Commit-ID: f6f58a77b49f1368b5883b3a1f776447cfcc7ef4
[email protected]