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
lookup to force some more uniqueness in queries to reduce the likelihood of
spoofing attacks succeeding.
Normally this should be hidden from the user by the resolver, but
in some cases it can leak through. When it does, it can mess up
ssh's CanonicalizePermittedCNAMEs.
Fix this by forcing the name we received from the system resolver to
lowercase.
bz3966, report and fix by Martin D Kealey
[1] https://datatracker.ietf.org/doc/html/draft-vixie-dnsext-dns0x20-00
OpenBSD-Commit-ID: e0b300d3b3af289e053d928380af71949f95bfb0
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.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
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
OpenBSD-Commit-ID: 25ef72223f5ccf1c38d307ae77c23c03f59acc55
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@
OpenBSD-Commit-ID: f05ad8a1eb5f6735f9a935a71a90580226759263
allocated, it's safe to start using the standard names for requesting agent
forwarding over the @openssh.com extension names we've used to date.
Support for the standard names is advertised via EXT_INFO. When the
client sees such support it will use the new names preferentially,
but the existing names remain supported unconditionally.
ok markus@
OpenBSD-Commit-ID: 1ab4a0b4de01e81a432875c2b7e5f7357e231af3
get a running mux process to show information about what channels are
currently open; ok dtucker@ markus@
OpenBSD-Commit-ID: 80bb3953b306a50839f9a4bc5679faebc32e5bb8
that shows connection information, similar to the ~I escapechar.
This is the first use of the mux extension mechanism, so it should be
both forward and backward compatible: a new client talking to an old
server will not allow the "conninfo" request to be sent, but everything
else should work seamlessly. feedback and ok djm@
OpenBSD-Commit-ID: 50f047a85da277360558cabdfed59cb66f754341
and ERR_load_crypto_strings(). These are no-ops in LibreSSL, and in
Portable have been mostly replaced by a call to OPENSSL_init_crypto()
in the compat layer. ok tb@
OpenBSD-Commit-ID: 4c3e0af10fe276766054eda34428a37a5606d3ea
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@
OpenBSD-Commit-ID: e2f0c871fbe664aba30607321575e7c7fc798362
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@
OpenBSD-Commit-ID: 325fc41717eecdf5e4b534bfa8d66817425b840f
key fingerprint and algorithm (not just algorithm number) as well as making
it explicit which keys didn't load.
OpenBSD-Commit-ID: ee3e77a0271ab502e653922c6d161b1e091f8fee
later during User token expansion we don't end up freeing a member of argv.
Spotted by anton@'s regress tests.
OpenBSD-Commit-ID: 2f671a4f5726b66d123b88b1fdd1a90581339955
with the exception of %r and %C which are self-referential. Requested in
bz#3477, ok djm@, man page improvements jmc@
OpenBSD-Commit-ID: caeb46251ee073662f6f5864c6f7b92d8ac80fa8
matching on the remote command specified on the commandline.
Also relaxes matching rules for `Match tagged` to allow
`Match tagged ""` to match an empty tag value. This also works
for command.
ok markus@
OpenBSD-Commit-ID: 00dcfea425bf58d824bf5e3464cfc2409121b60d
^x' commandline to be exactly two characters long. Avoids one by OOB read if
ssh is invoked as "ssh -e^ ..."
Spotted by Maciej Domanski in GHPR368
OpenBSD-Commit-ID: baa72bc60898fc5639e6c62de7493a202c95823d
This makes ssh(1) refuse user or host names provided on the
commandline that contain most shell metacharacters.
Some programs that invoke ssh(1) using untrusted data do not filter
metacharacters in arguments they supply. This could create
interactions with user-specified ProxyCommand and other directives
that allow shell injection attacks to occur.
It's a mistake to invoke ssh(1) with arbitrary untrusted arguments,
but getting this stuff right can be tricky, so this should prevent
most obvious ways of creating risky situations. It however is not
and cannot be perfect: ssh(1) has no practical way of interpreting
what shell quoting rules are in use and how they interact with the
user's specified ProxyCommand.
To allow configurations that use strange user or hostnames to
continue to work, this strictness is applied only to names coming
from the commandline. Names specified using User or Hostname
directives in ssh_config(5) are not affected.
feedback/ok millert@ markus@ dtucker@ deraadt@
OpenBSD-Commit-ID: 3b487348b5964f3e77b6b4d3da4c3b439e94b2d9
originally requested a tty; enables keystroke timing obfuscation for most
ControlPersist sessions. Spotted by naddy@
OpenBSD-Commit-ID: 72783a26254202e2f3f41a2818a19956fe49a772
multiplexed cases (inc. ControlPersist). bz3589 bz3589 Based on patches by
Peter Chubb; ok dtucker@
OpenBSD-Commit-ID: a7a2976a54b93e6767dc846b85647e6ec26969ac
This adds a ssh_config(5) "Tag" directive and corresponding
"Match tag" predicate that may be used to select blocks of
configuration similar to the pf.conf(5) keywords of the same
name.
ok markus
OpenBSD-Commit-ID: dc08358e70e702b59ac3e591827e5a96141b06a3
algorithms that are valid for CA signing. Previous behaviour was to list all
signing algorithms, including certificate algorithms (OpenSSH certificates do
not support CA chains). part of bz3577; ok dtucker@
OpenBSD-Commit-ID: 99c2b072dbac0f44fd1f2269e3ff6c1b5d7d3e59
Previously ssh would incorrectly refuse to canonicalise the hostname
if ProxyJump was explicitly set to "none" when CanonicalizeHostname=yes
bz3567; ok dtucker
OpenBSD-Commit-ID: 80a58e43c3a32f97361282f756ec8d3f37989efd
