Re: Systemd vsock sshd

[Pat Gunn <pgunn01 () gmail com>]

Would it be productive to reach out to the systemd maintainers to ask them
to have their software not do this and release a patch? This probably would
break some software that depends on the bad behaviour, but the fallout from
managing this may encourage them to think a little bit about security and
good software design in the future (tempted to add several paragraphs of
snark to this, but will omit).

On Mon, 29 Dec 2025 at 13:33, Greg Dahlman <dahlman () gmail com> wrote:

> Thank you Benjamin,
>
> Yes, the kernel boot string is the only way to currently mitigate the
> listener. The L4 loopback issue, which is a trivial extension, can only be
> mitigated by patching the kernel the way chromeOS did or reliably filtering
> af address family 40 (af_vsock) at the CRI, bubblewrap, etc… level with
> seccomp.
>
> The current state of apparmor and SElinux will make filtering at that level
> opportunistic at best. It should also be noted that adding the kernel boot
> string will be a breaking change for users who expect the hypervisor to
> have ssh access to guests for administrative purposes.  The trusted
> hypervisor, untrusted guest assumptions that vsock was based on are an
> important use case.
>
> For the listener specifically, a fix that would support both use cases
> would require modifying `systemd/systemd/src/ssh-generator/ssh-generator.c
> <
> https://github.com/systemd/systemd/blob/f76f0f99354b0485e3e13c2608bc26f969312687/src/ssh-generator/ssh-generator.c
> > `
> to allow control of the socket-activated sshd listener through a
> configuration file.
>
> The ssh-generator is just emitting typical systemd socket activation unit
> files, and I think the path that would be most productive if the
> relevant stakeholders were willing or if the distro's were willing to to
> patch the upstream source.
>
> As af_vsock is a convenient socket() like interface, there are still some
> use cases/projects that will break, but the above is the path forward that
> seems to minimise the impact.
>
> Greg
>
> On Mon, Dec 29, 2025 at 10:17 AM Benjamin McMahon <
> benjamin.mcmahon () webpros com> wrote:
>
> > To prevent the vsock-based sshd from auto-spawning, see
> https://www.freedesktop.org/software/systemd/man/devel/systemd-ssh-generator.html
> > In short: `systemd.ssh_auto=no` is the kernel-command-line setting which
> > persists after reboots.
> >
> > ~Benjamin
> >
> > ________________________________________
> > From: Jacob Bachmeyer <jcb62281 () gmail com>
> > Sent: Sunday, December 28, 2025 10:11 PM
> > To: oss-security () lists openwall com <oss-security () lists openwall com>;
> > Greg Dahlman <dahlman () gmail com>
> > Subject: Re: [oss-security] Systemd vsock sshd
> >
> >
> > [You don't often get email from jcb62281 () gmail com. Learn why this is
> > important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > On 12/27/25 21:46, Greg Dahlman wrote:
> > > [...]
> > >
> > >   **Systemd v256 change** - When the *openssh-server* package is
> > >   installed on a VM with vsock support, systemd now automatically
> > >   starts an *sshd* instance that listens on the **af_vsock** socket in
> > >   the **global network namespace** without any manual configuration.
> >
> > Obvious question:  what manual configuration is required to kill that
> > listener?
> >
> >
> > -- Jacob