How to host and manage Git repositories

Monday, October 28, 2013

In this post I explain how to setup and manage Git repositories on Debian Wheezy. We use a tool called gitolite to manage and control the access to Git repositories using a single server user account and SSH keys as an identification method. Hence, we do not have to create shell accounts on the server for each user.

Installation of Git and Gitolite

In order to reproduce exactly this tutorial you will need to install sudo. Otherwise you have to switch to a super user account to perform the commands starting with sudo without the word sudo. You can install sudo using the command:

apt-get install sudo
sudo adduser <your current username> sudo

The next step is to install git. You need it installed on both: server and local machine.

apt-get install git
Once git is installed, it might be of your best interest to configure a few global variables such as your real name and email:
git config --global <your real name>
git config --global <your email>

The next thing to do is to create a user that will own the repositories you want to manage. This user is usually called git, but any name will work, and you can have more than one per system if you really want to. The user does not need a password, but does need a valid shell (otherwise, SSH will refuse to work).

sudo adduser --system --shell /bin/sh --gecos 'git user' --group --disabled-password --home /home/git git

You may change the home path to suit your taste. A successful user creation will look similar to:

Adding system user 'git'...
Adding new group 'git' (310).
Adding new user 'git' (310) with group 'git'.
Creating home directory '/home/git'.

You will need a public SSH key to continue. If you already have a private key and you know what is that, just skip the next step. Otherwise, you may generate one on your local machine.

ssh-keygen -t rsa

The public key will be in $HOME/.ssh/ Copy this file to your server. For example, you can use scp:

scp ~/.ssh/

After that, the next step is to get and install gitolite.

su git
cd /home/git
git clone git://
sudo gitolite/install -ln /usr/bin/

Now we have to setup the first gitolite's administrator. You will have to rename the file if you do not like the username id_rsa.

gitolite setup -pk ~/

That last command creates new Git repository called repositories/gitolite-admin on the server. You can change the location of the folder repositories by replacing it with a symbolic link. Also, you can remove from the server once the previous operations is concluded.

Run git clone git@YOUR_SERVER_HOSTNAME:gitolite-admin on your workstation to clone the repository gitolite-admin to your workstation.

This repository that you just cloned contains all the files needed to create repositories for your projects, add new users, and defined access rights. Edit the settings as you wish, commit, and push. Once pushed, gitolite will immediately make your changes take effect on the server.

Create new repositories

Create a new directory for your project and add the files.

mkdir myproject
cd myproject
git init
touch readme.txt

Now commit and push everything:

git add .
git commit -a -m "initial"
git remote add origin git@YOUR_SERVER_HOSTNAME:myproject.git
git push origin master

Pretty easy! Next we will explain how to add new users and set access rights

Adding new users and setting access rights

Adding users is easy. First, gather the public SSH keys of all your users; name them <username>.pub, e.g. "" and "", and drop them into keydir/ of your local gitolite-admin repository.

Second, edit gitolite.conf. You can group users or repos for convenience. The group names are just like macros; when defining them, it does not even matter whether they are projects or users; that distinction is only made when you use the "macro".

@oss_repos      = linux perl git gitolite
@secret_repos   = myproject

@admins         = bob
@engineers      = matt
@interns        = alice
@staff          = @admins @engineers @interns

You can control permissions at the "ref" level. In the following example, interns can only push the "int" branch. Engineers can push any branch whose name starts with "eng-", and tags that start with "rc" followed by a digit. And the admins can do anything (including rewind) to any ref.

repo @oss_repos
    RW  int$                = @interns
    RW  eng-                = @engineers
    RW  refs/tags/rc[0-9]   = @engineers
    RW+                     = @admins

This above configuration means: (RW+=Read Write Push, R=Read, RW = Read Write). Then we have to execute the following command to add all new SSH keys and update the configurations.

git add -A 

Now commit and push everything:

git commit -a -m "Updated contributors and settings"
git push origin master

Alice and Bob will also have commit rights.

A convenient feature is what happens when you try to ssh git@YOUR_SERVER_HOSTNAME. Gitolite shows you what repos you have access to.

Enable public access to some repositories

If you are running a public project, you will have your users with commit rights, and then you will have everyone else. How do we give everyone else read-only access without fiddling with SSH keys? We just use git-daemon [2]. This is independent of gitolite and it comes with git itself.

sudo -u git git-daemon --base-path=/home/git/repositories/ --export-all
This will make all the repositories you manage with gitolite read-only for the public. Users can then clone projects like this:

To export only some repositories and not others, you need to touch git-daemon-export-ok inside the root directory (e.g. /home/git/repositories/some_project.git) of each repo that you want public. Then remove “–export-all” from the git-daemon command above.

Securing SSH server

First, I would suggest using fail2ban to prevent brute force login attempts and I would disable logging in as root via SSH. This means an attacker had to figure out both the username and the password making an attack more difficult. Change PermitRootLogin to "no" in your /etc/ssh/sshd_config.

I would open /etc/ssh/sshd_config, find the line that says #PasswordAuthentication yes, and change it to PasswordAuthentication no. Then I would also limit the users that can SSH to the server. Either by group or just specific users. For example, add AllowGroups group1 group2 or AllowUsers user1 user2 to limit who can SSH to the server.

Additionally, I would use TCPWrapper as an additional security layer. I would block all IP addresses in your /etc/hosts.deny by adding the following line:

sshd:  ALL

and open up SSH to specific IP addresses using /etc/hosts.allow. For example adding the following line.

Finally execute:
sudo service ssh restart


[2] Hosting Git Repositories, the Easy (and Secure) Way. 2013.

[2] Git on the Server - Gitolite. 2013.

[3] Android Tools: Using the Hierarchy Viewer.