On 4/2/26 05:25, Damien Miller wrote: > OpenSSH 10.3 has just been released. It will be available from the > mirrors listed at https://www.openssh.com/ shortly. > > OpenSSH is a 100% complete SSH protocol 2.0 implementation and > includes sftp client and server support. > > 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 > > Potentially-incompatible changes > -------------------------------- > > * ssh(1), sshd(8): remove bug compatibility for implementations > that don't support rekeying. If such an implementation tries to > interoperate with OpenSSH, it will now eventually fail when the > transport needs rekeying. > > * sshd(8): prior to this release, a certificate that had an empty > principals section would be treated as matching any principal > (i.e. as a wildcard) when used via authorized_keys principals="" > option. This was intentional, but created a surprising and > potentially risky situation if a CA accidentally issued a > certificate with an empty principals section: instead of being > useless as one might expect, it could be used to authenticate as > any user who trusted the CA via authorized_keys. [Note that this > condition did not apply to CAs trusted via the sshd_config(5) > TrustedUserCAKeys option.] > > This release treats an empty principals section as never matching > any principal, and also fixes interpretation of wildcard > characters in certificate principals. Now they are consistently > implemented for host certificates and not supported for user > certificates. > > * ssh(1): the -J and equivalent -oProxyJump="..." options now > validate user and host names for ProxyJump/-J options passed > via the command-line (no such validation is performed for this > option in configuration files). This prevents shell injection in > situations where these were directly exposed to adversarial > input, which would have been a terrible idea to begin with. > Reported by rabbit. > > Changes since OpenSSH 10.2 > ========================== > > This release contains some relatively minor security fixes as well > as a number of feature improvements and general bugfixes. > > Security > ======== > > * ssh(1): validation of shell metacharacters in user names supplied > on the command-line was performed too late to prevent some > situations where they could be expanded from %-tokens in > ssh_config. For certain configurations, such as those that use a > "%u" token in a "Match exec" block, an attacker who can control > the user name passed to ssh(1) could potentially execute arbitrary > shell commands. Reported by Florian Kohnhäuser. > > We continue to recommend against directly exposing ssh(1) and > other tools' command-lines to untrusted input. Mitigations such > as this can not be absolute given the variety of shells and user > configurations in use.
Is it safe (from a shell injection perspective) to pass inputs that are
sanitized for character set, but otherwise untrusted? For instance,
is it sufficient to limit usernames to ^[A-Za-z][A-Za-z0-9_-]{0,31}$
and domain names to valid host names [1]?
Can one assume that in situations where entries come from an
untrusted source (such as AuthorizedKeysCommand), OpenSSH _does_
do such checking?
[1]: No more than 254 bytes (plus optional trailing '.'), no leading '.',
each '.'-delimited component must start and end with [a-z0-9], not
be more than 63 bytes, and only have [a-z0-9-].
--
Sincerely,
Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
