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 gitOnce 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 user.name <your real name> git config --global user.email <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/id_rsa.pub. Copy this file to your server. For example, you can use scp:
scp ~/.ssh/id_rsa.pub git@YOUR_SERVER_HOSTNAME:id_rsa.pub
After that, the next step is to get and install gitolite.
su git cd /home/git git clone git://github.com/sitaramc/gitolite sudo gitolite/install -ln /usr/bin/
Now we have to setup the first gitolite's administrator. You will have to rename the file id_rsa.pub if you do not like the username id_rsa.
gitolite setup -pk ~/id_rsa.pub
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 id_rsa.pub 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. "alice.pub" and "bob.pub", 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 . This is independent of gitolite and it comes with git itself.
sudo -u git git-daemon --base-path=/home/git/repositories/ --export-allThis will make all the repositories you manage with gitolite read-only for the public. Users can then clone projects like this:
git clone git://YOUR_SERVER_HOSTNAME/PROJECT_NAME.git
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:
and open up SSH to specific IP addresses using /etc/hosts.allow. For example adding the following line.
sshd: 192.168.1.1, 10.10.0.0/255.255.0.0Finally execute:
sudo service ssh restart
 Hosting Git Repositories, the Easy (and Secure) Way. 2013. http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way/
 Git on the Server - Gitolite. 2013. http://git-scm.com/book/ch4-8.html
 Android Tools: Using the Hierarchy Viewer. http://mobile.tutsplus.com