Where
-Infinity
0

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.sshauto=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 afvsock socket in    the global network namespace without any manual configuration. Obvious question:  what manual configuration is required to kill that listener?

-- Jacob

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 (afvsock) 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 afvsock 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.sshauto=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 afvsock socket in the global network namespace without any manual configuration. Obvious question: what manual configuration is required to kill that listener?

-- Jacob

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203