sshfs isn't really what I wanted for my backup situation
Okay, it seems I missed the mark yesterday while telling my story about a dumb little backup scheme, because a bunch of people have reached out to ask "why not sshfs"?
So, okay, some assumptions, first. I'm assuming from some basic reading that sshfs is one of those things that lets you take a filesystem that's on a distant host and mount it (with FUSE, sigh) on a local host. If that is in fact what it does, that is very much *not* what I want.
I don't want my stuff to be visible as a filesystem on the remote host. That is, I don't want the copies of my data to be sitting there, accessible to anyone who can get on that machine. I want it to be a amorphous blob of (obviously?) encrypted data. The only place where it should make sense is on the client machine after I've supplied the key.
Speaking of keys, that key material (like a typed passphrase) never leaves the client system, since all of the crypto stuff happens locally. If this stuff was a regular filesystem on the other end, then that host would need access to the key, and then it's no longer really under my control, right?
Given all that, let me come at this again.
I have a host. I want to back it up to something that's not in the same physical location, and ideally is rather far away. Having different power companies, ISPs, you name it? That's all a good thing in this case. (Also, "different fault lines" is always a consideration here.)
I have access to that host, but assume I don't have root access to it for whatever reason. I'm just a user on there, and I can ssh in, and I have a healthy amount of disk quota. I'm also welcome to use oodles of (network) bandwidth to do whatever I need to do.
I don't, however, want the contents of my backed-up data to be visible to anyone on that host, _even if_ they have root on it, whether legitimately or otherwise. The remote host is just being a dumb block device for me.
I don't want to have any extra daemons running that would provide network access to the blob o' bits that constitutes the encrypted image. It's a whole bunch of extra complications that I don't need or want, since ssh gives me a perfectly good pipe without changing anything fundamental about how that system works.
So, the end result is that I extend nbd over a wacky ssh connection to a Unix domain socket on the source machine, do my crypto magic to make it into a viable filesystem, then fsck it, mount it, and rsync my stuff onto it.
The only part of this I had to create was the aforementioned wacky ssh connection. nbdclient itself won't do a "ssh to far end, start nbdkit server, and then stay alive copying bytes around" thing. It's all about getting the connection up and handing it off to the kernel. It only sticks around if it's doing TLS mode and since that means running a persistent server on the far end, I'm not using it that way.
That's it. It's just one of those dumb things you build to make other stuff possible. Tools to make tools.