 1️⃣3️⃣ Here's the 13th installment of posts highlighting key new features of the upcoming v256 release of systemd. ssh is widely established as *the* mechanism for controlling Linux systems remotely, both interactively and with automated tools. It not only provides means for secure authentication and communication for a tty/shell, but also does this for file transfers (sftp), and IPC communication (D-Bus or Varlink). 7 comments
Thing is though, that there are better ways to communicate locally: AF_VSOCK is an alternative to AF_INET/AF_INET6 for local communication between VMs and hosts. In many ways it behaves very similar to TCP. It is similar enough so that you can just do ssh-via-AF_VSOCK. As opposed to AF_INET/AF_INEt6 it requires next to no configuration, your really just have to enable the knob in your VMM, and have a somewhat non-ancient Linux distribution as guest. And ssh-via-AF_VSOCK is precisely what we are doing in systemd v256: a small new unit generator (i.e. a plugin that extends systemd's unit tree dynamically) detects if AF_VSOCK is available and sshd is installed, and if so binds AF_VSOCK/port 22 to sshd, via socket activation. Or in other words: in environments where AF_VSOCK is a thing, sshd will now *just* work, without any extra configuration and at minimal cost of resources (because lazy socket activation rocks). @ska dunno, this is free software, do whatever you want with our software. Use it or don't. It's all LGPL. Hacking up the ssh thing within our framework was easy, I wrote the generator and the proxy in 1h or so, since the building blocks are all there already. If you care about other OSes and so on, that's entirely OK by me. Take our code, or take inspiration from it, or take nothing at all. It's all entirely fine, but please don't pretend that we just did this within our own framework out… @ska … of malice. We just did it because it's easy given all the building blocks we need already exist in our framework, ready to use. I mean, there's a reason you have your own C library with tools, because you don't want to write all the basic building blocks from scratch either all the time. If you did that then this 1h job takes a *lot* longer. We do not share the same goals, so much is obvious, but always implying we do everything out of malice, is just getting badly on my nerves. |
Gregory's Server
It relies on TCP as network transport, which is great for remote operation around the globe but really sucks for local communication with a VM and similar, as it usually requires delegation of an address space, dhcp lease, dns and so on, which while manageable are certainly a major source of mistakes, fragility and headaches. In particular it means that logging into a system to debug networking doesnt really work since without working networking you cant even log in. Sad!