Hi all. Would appreciate some help if you can set me straight on remote replication setup. Sorry if it’s kind of a convoluted question.
I’m trying to set up two machines to do replication over tailscale, a main NAS and then a smaller one offsite as a backup. I’m using Syncoid and systemd timers to schedule replications.
I’ve seen several posts and guides that recommend using dedicated non-root user accounts to handle the replication process. Make user sendbot on machine A and user receivebot on machine B, give them access to replication using ZFS delegation, and let them send and receive over ssh without exposing root. Sounds great, I like this plan.
I’ve been digging, but I can’t really find much on how to actually set up the sendbot/receivebot accounts. The suggestions and tutorials mostly just gloss over that part and move on to ZFS delegation. Been using linux as a desktop for years, but never really got deep into user config and ssh until recently, and I’m still trying to wrap my brain around some of it.
The thing I don’t get is shell access and ssh with this setup. If I make an account with loginShell=/sbin/nologin, then I can’t connect manually through ssh to login and run commands. (Right?) But I’m not sure whether a system with an ssh key can still connect to a nologin account (with the corresponding public key) and run the command. Most of the things I’ve read seem to say that nologin blocks ssh regardless of password or key, but there’s always someone with an “actually, you can get around that by…” so I’m kinda confused.
My understanding is that I should make both users system accounts. Both need home directories for the keys and authorized keys stored in ~/.ssh. (Unless there’s a way to store those someplace else where the users can access them without twisting the whole system into a pretzel?) Is this the way to go about this?
The account on the machine that initiates the replication (regardless of push or pull) probably doesn’t need a login shell, since it’s starting the ssh and won’t be ssh’d into. Is this correct?
What about the machine NOT initiating, the one that gets ssh’d into? Does it need shell access to work with an ssh key stored on the other machine?
This article I wrote for Klara walks you all the way through the delegation process. Please read it all the way through before trying to make changes to your system–it’s not just a quick recipe, it walks you through each step one at a time, including showing you how things break if you don’t have certain steps finished yet.
There is a complete recipe for using delegation with Syncoid at the very end, but I strongly recommend reading the whole thing carefully before just following the recipe.
Hi Jim. Thanks! This is a great walkthrough. It’s actually the thing that got me started down this rabbit hole. The article walks through setting ZFS user permissions for send, receive, snapshot, etc with delegation. With this, sendbox and receivebox now have the ability to access the ZFS level operations. I mostly understand that part.
My question is about actually making sendbox and receivebox. Ie, when I run adduser sendbox, what parameters do I want to set? Do they need shell access, does only the non-initiating system need shell access, do they need home directories, etc.
I’d 100% love a recipe on what’s needed or what’s recommended, but I also want to understand why it’s the recommended combination for Syncoid. (As opposed to something like Prometheus that just sits quietly in a bare bones system account and logs data.)
From what I understand, this is what I’d want for a pull system where machine B initiates replication to pull from machine A:
User receivebox on machine B
System user
nologin for no shell access
Home directory for storing ssh keys
User sendbox on machine A
System user
shell access so machine B can ssh in
Home directory for storing ssh authorized keys
Does this setup seem right? Anything else I’m missing that would be beneficial to look at?
I’m learning, but definitely a noob at sysadmin. Just trying to check my understanding before I make an obvious mistake and leave an elephant-sized hole in the super high security system where I back up my Rick and Morty DVDs and my Abiotic Factor fan fiction, lol.
It sounds like you’re pretty massively over-thinking this, honestly. They just need to be standard unprivileged users, but yes, they must have a shell (either Bourne, or Bourne-compatible, like bash) because Syncoid is executing commands using their UID and GID.
They do not need access at the filesystem level to the stuff they’re replicating. You might, for example, chrgrp your entire ZFS pool to a group named privileged which senduser and/or recvuser as appropriate do not belong to, then chmod the pool root 770–making an attempt by senduser or recvuser to cd /mypool error out–that would not impact their ability to replicate the pool via syncoid, for backup purposes.
Negative, ghost rider. If you can’t ssh senduser@A zfs send blah@1 manually, Syncoid can’t do it for you, either.