Ideas for BorgServer v2 - incl. breaking changes!

[Nold360]

BorgServer v2

Ideas:

• Don't run sshd as root [breaking change]
  -> Only root can expose ports < 1024 on linux, so the defaut port would change
• Different authorized_keys handling
  1. Git-Based: Simply push all your public keys to git & your good to go. (nice for k8s)
  2. Replace the static-generated authorized_keys-file with a more dynamic script, that reads all keys when a client connects (Using sshd_config/"AuthorizedKeysCommand")

I think i would simply provide both methods using labels, :latest would stay directory based.

@abmaonline do you got anything in mind?

[abate]

I've done a bit of work for the second point here : #7

This adds the possibility to pull from a git repo and update the keys using a cronjob

As a side note (not related):

• using alpine instead of debian would reduce the size of the image considerably and also the attach surface ( but the docker file needs to be amended to rebuild borg from source )
• using bash for scripting critical services (like backup) make me uneasy. I think these kind of services deserve to be written in a real programming language . Golang is really popular these days for these kind of applications.

[Nold360]

@abate:
On alpine: I'm an oldschool linux admin, love the stability of debian and i'm used to it.. I've already seen ppl. building alpine images but i don't really like pulling stuff directly from source. So for stability i rely on the debian package maintainers. [your awesome!]
Also with ~40MB compressed size of the image right now, i think the size is Okish 😄

But feel free to contribute a alpine-based Dockerfile! We could add it as an additional tag to the project :)

On Bash:
Again, linux-guy, no-dev. ;-) That's while i write a lot of bash and working with environment variables is just easy. But surely everything could use some cleanup. As for a rewrite I would try to go the python road instead of go cause borg is also written in python and might integrate better.

[abate]

I've played with alpine and borgbackup is already in alpine 3.10 ! so there is no pulling from source.

https://github.com/abate/docker-borgserver/blob/alpine/Dockerfile.alpine

I'm going to test it a bit more and maybe I'll propose another MR. You could simply have the
two images available with two different tags. For me using alpine is a bit about the size, but
also he fact that the surface attach is reduced. I love to play with these things, but I'm old
debian person as well. So having debian is actually something I prefer.

[dokbua]

May I add a suggestion? :)

After having installed this on server and a couple of clients, both local and remote, I think the /sshkeys/clients "hack" you made in run.sh is really clever, considering how it has to integrate with BB -- but the practical implementation confuse me a bit.

When you create keys they're traditionally called id_rsa and id_rsa.pub. To not have your host become something.pub you'd have to rename the public key to something else, and it will no longer be obvious what you're looking at.

My suggestion is to change from /sshkeys/clients/whatever to /sshkeys/whatever/id_rsa.pub - with whatever being whatever you want to call the client. This would also allow you to store your private key in the same directory, and you could give the client a sensible name and still know that your id_rsa.pub key is what it is. If the directory isn't host, it is by definition a client so the clients directory isn't really necessary IMO.

I'd be happy assisting in the rewrite if that is any help. Like you I'm a veteran Linux sysadmin comfortable with shell scripting.

PS. For now I actually implement this by adding my keys as above and linking them to the clients directory (unfortunately symlinks cause the server to not want to start)

[Nold360]

My suggestion is to change from /sshkeys/clients/whatever to /sshkeys/whatever/id_rsa.pub

TL;DR: No.

What if you're machine is called 'host'? we would have to move it somewhere else, to avoid collisions.. also the path is called /sshkeys/clients/, so it should be pretty clear what it contains.. but we can call the keys: host.pub, so host will be the borg repo-name. But I hate this volume anyways, it's never been a good solution. this is why i want borgserver:v2 (TM) to load all client keys from git. Hostkeys on local volume you don't need to care about too much. And we can all chill ~

[dokbua]

It was my understanding the names are just what you decide to call the servers, so in the unlikely situation that you have a server called host you can just call it something else. Anyway, no big deal, like I explained I actually find my work-around works 98% perfectly. If I could use symlinks it would be 99% (I like to see how things link together).

[rexzhang]

Could you support 1 read/write ssh key and 1+ read only key in one repos?