

This is apparently the case in the whole industry and its ridiculous.
This is apparently the case in the whole industry and its ridiculous.
I understand this, but this is inconsistent behavior. You now use 22 inside your network and something else outside. Whenever you create inconsistent behavior, everyone using it has to have an awareness of all these inconsistent behaviors.
Also, it is hard to troubleshoot because the tool most admins would want to use (netstat) will not give you useful information to understand the situation.
If you change it, definitely change it on the server so it shows up in netstat and is consistent.
The idea behind keys is always, that keys can be rotated. Vast majority of websites to that, you send the password once, then you get a rotating token for auth.
Most people don’t do that, but you can sign ssh keys with pki and use that as auth.
Cryptographically speaking, getting your PW onto a system means you have to copy the hash over. Hashing is not encryption. With keys, you are copying over the public key, which is not secret. Especially managing many SSH keys, you can just store them in a repo no problem, really shouldn’t do that with password hashes.
This is mostly nonsense.
Don’t just copy random config from the internet, as annoying as it is, read the docs.
Every person and institution saying that is what enables fascism.
If you are sure that every household can only change their own data, and not that of anyone else, meaning there is only one “true copy” for every file, then yes, you can just replicate that to the other locations.
I do not consider Authelia secure from an architecture point of view.
That is because there is, by design, no authentication between authelia and the backend. That means that if anyone ever manages to directly access the backend services, they can impersonate anyone, including admin.
I want to write this in a separate post because I see many questionable suggestions:
Your scenario does not allow for a simple rsync / ZFS copy. That is because those only work with 1:many. Meaning one “true” copy that gets replicated a couple of times.
As I understand you have a many:many scenario, where any location can access and upload new data. So if you have two locations that changed the same file that day, what do you do? many:many data storage is a hard problem. Because of this a simple solution unfortunately won’t work. There is a lot of research that has gone into this for hyperscalers such as AWS GCP, Azure etc. They all basically came to the same solution, which is that they use distributed quorum based storage systems with a unified interface. Meaning everyone accesses the “same” interface and under the hood the data gets replicated 3 times. So it turns it back into a 1:many basically, with the advantages of many:many.
So I think this can be achieved in different levels of complexity.
First of all, you may want to look into ZFS, because there you can have multiple “partitions” that all have access to the entire free space of the device or devices, meaning you won’t need two separate drives. Or probably you want multiple smaller and cheaper devices that are combined together because it will be cheaper and more fault tolerant.
You also need some way to actually access the data. You have not shared how that is supposed to work: smb/nfs, etc. In either case you need a software that can do that. There a various options.
Then, you probably want to create some form of overlay network. This will make it so that the individual devices can talk to each other lime they are in the same lan. You could use tailscale/headscale for this. If you have static public IPs you can probably get around this and build your own mesh using wireguard (spoiler: thats what tailscale does anyway).
Then, the syncing. You can try to use syncthing for this, but I am not sure it will work well in this scenario.
The better solution is to use a distributed storage system like garage for this, but that requires some technical expertise. https://garagehq.deuxfleurs.fr/
Garage would actually allow you to for example only store two copies, so with three locations you would actually gain some storage space. Or you stay with the 3x replication factor. Anyway, garage is an object store which backup software will absolutely support, but there is no easy NFS/smb. So your smart TV, vanilla windows or whatever will not be able to access it. Plus side: its the only software you need, no ZFS required.
Overall its a pretty tricky thing that will require some managing. There is no super easy solution to set this up.
Your requirements are really unclear.
Who says the authoritative servers aren’t logging requests?
That should only happen with SNI, no?
The queries are known to the DNS provider. Only thing is to use one you trust.
The only thing you gain from VPN is that the target server does not know your IP.
HTTPS is safe anyway and as such also the content of what you do.
The only other way you may leak information are DNS queries.
Peoples opinions are very much shaped by social pressure.
I mean that’s pretty easy to build yourself. You can write a super simple web app and on get it displays a message then deletes it from database.
So containers have been standardized for a while now (OCI), and even if you install “docker” it’s actually just installing containerd with docker-cli. For years kubernetes is not even supporting docker-shim anymore. So there should be no issue. What is even the problem you are running into?
I would recommend something like stalwart, which is just a single binary and works. Gives you a web interface and a zonefile you can just copy paste into your DNS including all correct DMARC DKIM SPF and autodiscovery records.
Setting postfix, dovecot etc. up from scratch can be a bit time consuming and annoying.
Deliverability depends on where it is hosted, many VPC providers IP space is completely blocked in spam filters.