Ytdyklly

I need to build a git server where certain users have a read-write access to the repository and management server running certain scripts using this repository has the read only access to the same repository in the git server:

The setup should be as secure as possible. At the moment I accomplished this with gitolite where devices repository has following configuration:

repo devices

    RW     =   eng1

    RW     =   eng2

    RW     =   eng3

    R      =   graphs

SSH key-pair for user graphs is stored in mgmt-svr server in user graphs home directory and private key is readable and writable only for the user graphs. This private key is not password protected.

Is there a more secure way to accomplish this? I thought about using HTTPS to access the devices repository in git server and basic access authentication, but I can't see any advantages over the current SSH based setup- I still need to store the access credentials somewhere in the user graphs home directory.

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.

You can use gitlab and the deploy key feature for CI. This feature is available for the community edition (ce), too.

Global Shared Deploy keys allow read-only or read-write (if enabled) access to be configured on any repository in the entire GitLab installation.

This is really useful for integrating repositories to secured, shared Continuous Integration (CI) services or other shared services. GitLab administrators can set up the Global Shared Deploy key in GitLab and add the private key to any shared systems. Individual repositories opt into exposing their repository using these keys when a project maintainers (or higher) authorizes a Global Shared Deploy key to be used with their project.

Global Shared Keys can provide greater security compared to Per-Project Deploy Keys since an administrator of the target integrated system is the only one who needs to know and configure the private key.

GitLab administrators set up Global Deploy keys in the Admin area under the section Deploy Keys. Ensure keys have a meaningful title as that will be the primary way for project maintainers and owners to identify the correct Global Deploy key to add. For instance, if the key gives access to a SaaS CI instance, use the name of that service in the key name if that is all it is used for. When creating Global Shared Deploy keys, give some thought to the granularity of keys - they could be of very narrow usage such as just a specific service or of broader usage for something like “Anywhere you need to give read access to your repository”.

Once a GitLab administrator adds the Global Deployment key, project maintainers and owners can add it in project’s Settings > Repository page by expanding the Deploy Keys section and clicking Enable next to the appropriate key listed under Public deploy keys available to any project.

https://docs.gitlab.com/ee/ssh/#deploy-keys

EDIT:
gitea is a more lightweighted selfhosted git service compared to gitlab. It has just a static single binary file without any dependencies - programmed with go (you need to add config files and a systemd service or similar of course). The website has a nice overview of it's features:
https://docs.gitea.io/en-us/