Re: Systemd vsock sshd

[Greg Dahlman <dahlman () gmail com>]

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