secure read-only self hosted git repository for scripts

The setup you have sounds quite secure. Though hackers will always find a way given enough time. ...Don't sue me if someone hacks you. It might be appropriate for a small setup. For a large team in a large business it might be less appropriate (see "Social Engineering" below).

There are some good points about it and some points for you to consider to make it better.

Positive points about your setup

• Gitolite is itself light weight and well used enough with continuing updates. (last commit 23 days ago at time of writing). It's pretty secure.
• Gitolite piggybacks off OpenSSH server which is very well supported and extremely secure.
• Public private keys (such as SSH keys) are far more secure than passwords
• The setup is very simple giving you less to go wrong, and a cheap solution.

Considerations for improvement

Un-encrypted Keys

Storing your private keys un-encrypted isn't perfect, though it is common. As you say you have to store them somewhere. However this can be a problem with backups or with servers that aren't physically secure. There are options which require you to manually decrypt your private keys when you reboot your server. Perhaps the simplest of these is an ssh agent and manually add your encrypted key to it when you reboot.

SSH server hardening

Remember that Gitolite runs under OpenSSH server. There are a number of things you can do to harden the ssh server itself.

You might even consider running Gitolite under a chroot environment. There are many tutorials for how to setup chroot with OpenSSH. Remember that the result will need access to programs like python so this will make it more technically complex to achieve than many of the tutorials would have you believe.

Social Engineering

Every sysadmin looks for the technical ways a hacker can get in, but so many real world hacks are down to people.

Perhaps the weakest point of your solution is the management of ssh keys. This is widely regarded to be a security issue in many businesses. Gitolite places all of the administration of SSH keys on the administrator. This carries some big implications:

• With no support for single sign on, the sysadmins may not know they need to remove access to this specific box when someone leaves. Eg: if your team is running this box for themselves, will they be notified the minute an employee is sacked?
• The naming convention inside Gitolite's config isn't great. It's very easy to make mistakes and delete or replace the wrong key. You need to come up with a directory structure for yourself that makes it absolutely clear what you are doing.
• Users may not tell you when they stop using a key. What they do with that key next may not be secure. Other, larger, software such as Github Enterprise actually has built in features for auditing SSH keys by disabling them on mass and asking users to re-approve them.