Setting up a gitolite server in Ubuntu

In the middle of last night, I decided to finally get my local git repository back on my server before going to bed. I was too lazy to read any detailed documentation, so I just googled a few howtos. None of them was entirely complete, so the following is culled from a small number of them.


I had a server running Ubuntu 12.04 and a client (running the same version, but any Linux distribution should do). The client already had git installed, with a local repository I’d been using for a while. I wanted to get a git server running on the server and push the local repository there, so that when everything was done, the local repository would just be a clone of the main one on the server.

I’d read about gitosis repeatedly, but as it turned out, Ubuntu had dropped support for that in favour of gitolite, so that’s what I ended up putting on the server.


All the necessary packages are in Ubuntu’s standard repositories:

sudo apt-get install git gitolite

We’ll be handling gitolite via a separate user, so we have to create it (sans password, so no direct logins possible):

sudo adduser \
  --system \
  --shell /bin/bash \
  --gecos 'git version control' \
  --group \
  --disabled-password \
  --home /home/git \

Access to gitolite will be authenticated via SSH keys. If the user we’re installing gitolite with doesn’t yet have a SSH key pair, we can create one:

ssh-keygen -t rsa

We’ll need the public key for the git installation. As the git user doesn’t have access to our .ssh directory, we copy the key file to the temp directory:

cp ~/.ssh/ /tmp/

Now we can login as the git user and setup gitolite:

sudo su git
echo "PATH=$HOME/bin:$PATH" > ~/.bashrc
gl-setup /tmp/

gl-setup will open the gitolite config file in the editor, but we can just accept the defaults by saving and closing.


Back in our regular user account, we can now clone the gitolite-admin repository, which is used to change the repository configuration:

git clone git@localhost:gitolite-admin.git

We’ll be using gitolite-admin to add the login key for our remote user and to create a new repository.

First, let’s allow the remote user (on the client system) to access gitolite. We need the user’s public key file (if the user doesn’t yet have a key pair, see above).

gitolite expects all key file names to follow the pattern <username>.pub. They can, however, be nested in sub directories. Since the same user may have different keys on different machines, we use a separate directory for each client to store the key files:

mkdir gitolite-admin/keydir/myclient
cp gitolite-admin/keydir/myclient/

We can now add a new repository and give our user access to it by editing gitolite-admin/conf/gitolite.conf, like so:

repo    gitolite-admin
  RW+     =   local

repo    testing
  RW+     =   @all

repo    mynewrepo
  RW+     =   myusername

The first two repositories were already configured. I added “mynewrepo” and gave “myusername” full access to it. Multiple users can be specified by multiple permission lines for a repository. The “@all” keyword can be used to grant permissions to all users who have access to gitolite.

To activate these changes, we simply have to commit and push gitolite-admin:

git add -A
git commit -m 'New user keys and new repository.'
git push origin master

The new, empty repository should now be available and you should be able to do this on the client system:

git clone git@myserver:mynewrepo.git

Note that gitolite repositories are always access as the “git” user. gitolite will recognise your actual user via your SSH key and use the appropriate permissions.

Pushing the existing repository to the server

The only thing missing now is making the newly setup server the origin of the git repository we already have. This is simple, just do this from within the local repository’s directory:

git remote rm origin
git remote add origin git@myserver:mynewrepo.git
git push origin master



This entry was posted in git, Uncategorized and tagged , , . Bookmark the permalink.

23 Responses to Setting up a gitolite server in Ubuntu

  1. Mike says:

    Excellent, exactly what I needed and very easy to follow!

  2. Pingback: Cómo instalar gitolite en Ubuntu 12.04 | @lobo_tuerto

  3. My brothеr гeсommendеԁ І may likе this blog.
    He was totallу гіght. Thiѕ ρost
    aсtuallу made my day. You cann’t imagine simply how so much time I had spent for this information! Thank you!

  4. Steven Scott says:

    Excellent document, clear, concise, works, and just what I needed.

    Couple small typos though:
    The copy path for the RSA key has a typo, you have /temp/ instead of /tmp/
    cp ~/.ssh/ /temp/
    should be
    cp ~/.ssh/ /tmp/

    Not instead of now:
    Back in our regular user account, we can not clone the gitolite-admin repository,
    should be
    Back in our regular user account, we can now clone the gitolite-admin repository,

  5. Pingback: Ubuntu安装Git服务器 | sunshine-wang

  6. Pingback: Git | AbacusHill

  7. chizuoka says:

    I had this error trying to clone…i just copy and paste almost everything.. except the location of the pub file which seems different on my machine.

    Cloning into ‘gitolite-admin’…
    The authenticity of host ‘localhost (’ can’t be established.
    ECDSA key fingerprint is ac:35:4e:73:35:12:1e:86:a3:2a:5e:57:01:2e:30:d1.
    Are you sure you want to continue connecting (yes/no)? y
    Please type ‘yes’ or ‘no’: yes
    Warning: Permanently added ‘localhost’ (ECDSA) to the list of known hosts.
    Permission denied (publickey).
    fatal: The remote end hung up unexpectedly
    ubuntu@ip-10-130-15-40:~$ git clone git@localhost:gitolite-admin.git
    Cloning into ‘gitolite-admin’…
    Permission denied (publickey).
    fatal: The remote end hung up unexpectedly

    • Can you connect to your system with SSH using your public key – i.e. does the following work without asking you for a password:

      ssh localhost

      • Bob says:

        I have the exact same problem… I can “ssh localhost” without problem, but “git clone git@localhost:gitolite-admin.git” results in a permission denied.

        • Bob says:

          Fyi, for anyone else who might have a similar problem… my issue was that in my /etc/ssh/sshd_config, I forgotten that I had set the “allowusers” parameter to be very restrictive. I’m guessing that the “git” user is the one that makes the ssh connection, which was being denied by ssh.

  8. chizuoka says:

    You also missed the
    # cd ~/.ssh
    before the
    # ssh-keygen -t rsa -f keyname

    hence the location of keyfile was wrong.

    • If you specify the -f option, you have to also specify the path to the key (or run the command in your desired directory). If you skip the -f option, as in my examples above, the key will by default be created in your ~/.ssh directory.

  9. shgninc says:

    Hi there. First, Thank you so much.
    Second, let me ask my question.
    after all thing you said in your post, i did. i have a problem by
    # git clone git@myserver:mynewrepo.git
    and give this error:

    “Cloning into ‘blog’…
    R access for blog DENIED to local
    (Or there may be no repository at the given path. Did you spell it correctly?)
    fatal: The remote end hung up unexpectedly”.

    so i can not push to my git repository???!

  10. Pingback: Ubuntu12.04使用Gitolite安装Git Server | 纷纷说

  11. Aryo says:

    The last scripts before pushing existing repository to remote server (origin), so that I had to commit my local repository first:
    git remote rm origin
    git remote add origin git@myserver:mynewrepo.git
    git commit -m "initial commit"
    git push origin master

    If I don’t commit, I had this error:
    error: src refspec master does not match any.

  12. Michael says:

    I got confused by which should run the client side or which should run on the server.

  13. Pingback: git 伺候機 ( sū-hāu ki ) 設帳(siat-tiùⁿ ) | 暗号學筆記

  14. Reyes says:

    Pretty! This was an incredibly wonderful post. Thanks for
    supplying this information.

  15. Pingback: Gitolite Ubuntu 14.04 LTS - Frank the DevOp

  16. Pingback: Gitolite Konfigurieren - Frank the DevOp

Leave a Reply

Your email address will not be published. Required fields are marked *