Re: Announce: OpenSSH 10.3 released

[Damien Miller <djm () mindrot org>]

On Fri, 3 Apr 2026, Demi Marie Obenour wrote:

> >  * 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]?

Probably, but this is the essence of the problem as we see it: we can't
know for sure whether this is safe, because we don't can effectively
reason about what shell is in use (and thus what its metacharacters
are) and what the user is doing with these characters in their
configuration file.

To make things harder, this isn't the full set of characters that
appear in usernames. At least %, @, \ and / are relatively common
too :(

> Can one assume that in situations where entries come from an
> untrusted source (such as AuthorizedKeysCommand), OpenSSH _does_
> do such checking?

The *Command options in sshd_config require that the user exist
in the system password database, otherwise they will not be
executed.

It's still possible to shoot youself in the foot with these if you
try hard enough though, e.g. if you've rigged NSS to allow arbitrary
usernames with no character filtering, then there is the potential
for shell injection if the admin has specified token expansion in
a *Command directive.

> [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-].

This too would block some hostnames that people use frequently.
As a trivial example, '_' is common in hostnames despite being
strictly invalid. IIRC there are other more esoteric ones too.

-d