Thanks for the reply Alex,

I didn't include that option because I ran into an issue that I couldn't find the root cause for. Specifically on Fedora, a dnf upgrade resulted in the mask disappearing. I could find some complaints with Fedora version upgrades, but couldn't find anything on package upgrade.

As I don't have access to the RedHat support portal I decided to exclude it out of caution.

It looked like there was nothing in /usr/lib/systemd/system-preset for sshd-vsock.socket that I found, and those should respect the mask for sshd-vsock.socket and wouldn't remove the /etc/systemd/system/sshd-vsock.socket symlink as I understand it.

I think that because it doesn't show up in busctl --activatable, and no packages I can find "Wants" sshd-vsock.socket explicitly that would probably work.

I just tried a fresh install of Fedora Linux 42 workstation and didn't experience the unintended unmasking with a dnf upgrade. That was reliable a few weeks ago. Maybe I just was unlucky with a package that was fixed?

Either way I think it is an option for people who use configuration management tools that can periodically check sshd-vsock.socket is still disabled.

Also for normal systemd services that need isolation from the vsock bridge you can use:

RestrictAddressFamilies=none # disable all af families RestrictAddressFamilies=AFINET # only AFINET RestrictAddressFamilies=~AFVSOCK # not AFVSOCK

The L4 bridge problem will be harder for projects that use CRI's that are not containerd like the k8s/podman/crun/runc.

If anyone on here is involved with them, or sandboxing tools like bubblewrap etc... Filtering address family 40 will still be required by default to have any real intra-container/pod/process network isolation on a node.

Thanks,

Greg

On Tue, Dec 30, 2025 at 12:12 PM <wish42offcl98 () posteo org> wrote: I have searched for that - instead of blacklisting the vsock module, I did myself two measures: - systemctl mask --now sshd-unix-local.socket to kill and mask the sshd unix socket created by that generator, - systemctl mask sshd-vsock.socket to mask the sshd vsock created by that generator (use --now if the socket has started or use systemctl stop... ).

Though, vsock untested but I found that source mentioning that socket. https://linux-audit.com/system-administration/commands/systemd-analyze/ Masking the sockets should stop them from starting again.

The vsock kernel module should not be blacklisted if some hypervisor features are required: https://libvirt.org/ssh-proxy.html https://wiki.qemu.org/Features/VirtioVsock

Greetings Alex

On 12/29/25 05:11, Jacob Bachmeyer wrote: 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