At least, I hope.
The problem: I need git. Ok, go github. Yapp, but I need the git for some sensitive-ish data. Nothing really sensitive, or confidental, but yeah, no github.
Ok, then have my own. Easy, git init –bare and bascially all set.
We are ready.
Hm, but I know I usually forget to update the git tree on all the nodes I already deployed. I need, really need automatic updates.
Ok, create a timer, a service and a script (Do you rember when it was only one line in the crontab?) whatever.
Oh wait. The git repo is available via ssh. I don’t want to put my private key on all the nodes…
Hmm, create a new keypair, only for the git use:
ssh-keygen -f git_id_rsa
Put it any convenient folder, and set up the server side. Put the public key into the authorized_keys and prepend with the “command” stuff (adapt to your system):
$ cat .ssh/authorized_keys command="git-upload-pack '/home/fisher/git/?????.git'" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCpbipOc6rtzXH5B7vhQ.....
This forces anyone using this key to run this command only.
Now pimp up the git to use the ssh command a bit differently:
git -c core.sshCommand="ssh -i whereverisyourkey/git_id_rsa" pull origin master
Craft this command into your systemd service file, or crontab or any other scheduler something.
Uh, this is baaad, anyone has the (private) key, can steal your full git repo!
Absolutely true. But if someone managed to get this key, then probably already took the full repo too (and many other things). But this key allows a read-only access so cannot alter the repo content. Unless if there is a way in the git protocol, I never checked, tbh. And the important thing, this key not allows remote login.
Note: if the attacker manages to alter the repo content and somehow able to push it into your central git server, you are in trouble.
Pff… why bother then with all this crap? See above. You get automatic updates, and even can push the changes if you log in with your private key (or use your secure password).