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=AF_INET # only AF_INET RestrictAddressFamilies=~AF_VSOCK # not AF_VSOCK 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 <[email protected]> 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 **af_vsock** socket in > >> the **global network namespace** without any manual configuration. > > > > Obvious question: what manual configuration is required to kill that > > listener? > > > > > > -- Jacob > >
