ssh into container via VSOCK instead of via sshd.service?

[null-dev]

I think this is related to #236 but I'm opening a separate issue just in case, feel free to merge it into the other issue if needed.

bcvk ephemeral ssh requires sshd.service/sshd.socket to be running in the VM to work. On many distros/images, this is not the case.

systemd includes systemd-ssh-generator, this generator seems to be enabled by default on most distros. This means that on most distros, if systemd detects it is running in a VM, it will automatically listen on port 22 on the VM's AF_VSOCK, and start an sshd session for each incoming connection.

Maybe it would be worth switching bcvk ephemeral ssh to use this mechanism for better compatibility since all the configuration is already there (bcvk already allocates a VSOCK for each VM)?

Sample

Consider the quay.io/fedora-ostree-desktops/silverblue:43 image, sshd.service/sshd.socket is not enabled by default for this image so bcvk ephemeral ssh doesn't work:

❯ podman pull quay.io/fedora-ostree-desktops/silverblue:43
[...]
❯ bcvk ephemeral run -d --rm -K --name foo quay.io/fedora-ostree-desktops/silverblue:43
22850769c7f70368500ff696bb7d4084644cf2aaeaf9cd983afd1d44ed242cdb
❯ bcvk ephemeral ssh foo -v
Error: 
   0: Timeout waiting for readiness after 240s (221 attempts)

Location:
   crates/kit/src/utils.rs:71

However, I can ssh into the container over VSOCK, thanks to systemd-ssh-generator and systemd-ssh-proxy:

❯ podman exec -it foo ssh -i /run/tmproot/var/lib/bcvk/ssh 'vsock%3'
Warning: Permanently added 'vsock%3' (ED25519) to the list of known hosts.
[root@fedora ~]# 

Notes

More info:

• https://github.com/systemd/systemd/blob/2ba910ab06e5970e9e2dc6d28a8d38a4adcd4a16/NEWS#L3509-L3583
• Try contacting this VM's SSH server via 'ssh vsock%1' from host. systemd/systemd#39640

[cgwalters]

Yeah, the vsock stuff is cool. However, there's three issues.

1. IMO vsock without the relatively-recently merged vsock namespacing is dangerous to do by default. See e.g. Create installation VM and run bootc install inside a VM using rootless podman podman-bootc#95 (comment)

In this case I think it's OK, ssh has authentication. But the way systemd exposes its progress over vsock by default means literally any VM or the host can read systemd status from any other VM! Kind of wild.

This is fixed with torvalds/linux@099ca41 but that's still quite new.

2. we try to support rhel9-era systems at least here, which doesn't have that. So we'd have to special case - doable of course

3. I've hit issues where some host environments have vsock disabled (default Ubuntu host in github codespaces e.g.) and so we need a fallback for that too