Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I've been reading a lot of documentation on gitosis recently, but I am admittedly new to ssh keys and in turn, I seem to only have a rudimentary understanding of how gitosis actually works with git to provide access control.

But in reality, my research has gone on too long and I feel like I can't turn the corner on understanding this one thing in Gitosis. That would be:

1) Where the heck do I install Gitosis on my Debian server? In /home/git/ ? Or /usr/bin/ ? In the repository itself under /var/www ? this is one thing that doesn't seem to be covered in the various blogs entries I've read on the subject of installation. Yet, it seems like a fair question.

2) Some blogs say to use a public key, some allude to a private key. some seem to say leave off a password for whatever key they want you to use. Others say that leaving the password field blank will make everything unsecure. So this has me completely confused.

3) All I want to do is add myself and two other developers to have access to a dev server so they can push code from one directory (let's say their own sandbox) to the www/html dev directory on the same server (for release to internal testing). Then I want to push code to another server from there once it's been tested. Is it really so hard to set up? should I add git AND gitosis to the live server?

I was using this page listed below among others for reference and understood most of it. just not the parts about what I'm asking about above. thanks.


share|improve this question

1 Answer 1

up vote 3 down vote accepted

1: As far as installing gitosis goes, you fetch its "source" to whatever directory you please. The setup.py script has default locations it will use for installing everything to. Debian's gitosis package will install the files listed here. As for your code, gitosis manages the repository in the "git" user's home directory. From there you will need to pull a working copy for the actual website. There's a page here on using git to manage websites here that has some ideas for automating this, though you'll need more elbow grease to handle the staging vs. production issues. Also, see #3.

2: SSH uses a public/private keypair. The user keeps the private key secret at all times, then gives out the public key to whatever servers that user wants to log in on (thus, if someone "steals" the public key, the best they can do is let the user log in to their server). The gitosis-init command given at the tutorial you linked takes the public half of the key and adds it to the list of SSH's authorized_keys for that "git" user you created, with special settings that force anyone logging in using the private key half to only be able to use gitosis.

3: You'll have to decide on this based on your access controls. If your team has shell access on the production server, the simple thing to do would be to git pull all the updates from gitolite to the production server. If you don't have shell access then you'll need to set up some kind of service for pushing the site to the production server, which would probably be easiest using rsync or scp or something similar.

How SSH makes Gitosis Work

There are several key pieces to ssh that make gitosis work:

The first piece is the public/private key system which allows users to log in using the keys rather than using the account's password. This is what lets multiple people all use the same ssh username ("git") to log in.

The next part is the authorized_keys file. All of the public keys that are permitted to log in to this "git" account are stored in this file. When you connect, you and the server exchange information based on the keys (without actually transmitting the key itself) to prove that your private key matches one of those authorized public keys. In order for your client to do this, if you've set a passphrase on your key (which actually encrypts the key itself) you'll need to give your client the passphrase.

The "magic" of gitosis is that the authorized_keys file can be configured to force a particular key to run a particular command. What gitosis-init does (in addition to setting up gitosis's own "special" configuration repository) is take the public key it is given and adds it to the authorized_keys file with the command forced to a program that identifies the actual owner of the key and connects the remote git program to the local git repository (this command being gitosis-serve username). Note that gitosis-init should only be used once, after that all changes are made through the configuration repository: you will add your other developers' public keys (which they should generate themselves, keeping the private key private and giving you only the public key) into that repository and push the configuration back to the server. gitosis will automatically add the authorized_keys lines with their user information when this is done.

share|improve this answer
Thank you for such a detailed answer. Very appreciated. So in the case of being told not to worry about adding a passphrase...I should ignore that and add a passphrase then shouldn't I? And the passphrase will be the same for both public and private? that's what I absolutely don't understand. –  user75295 Mar 21 '11 at 23:19
When I generate the rsa key using keygen from the command line, it only asks me for one passphrase and generates two keys. which key does that passphrase go to anyway. Most of these instructions I've been following pretty blindly, but I think it's time I tried to understand why I have to do all these things. Like this command 'sudo -H -u git gitosis-init < /path/to/public_key.pub' I would LOVE to know wtf this actually does. It doesn't work on my Debian server anyway since it tells me "sudo cannot be fouund" but that's a sadness I'm also looking into separately. –  user75295 Mar 21 '11 at 23:22
@user75295 The private key (the file not ending in .pub) is the one protected by the passphrase. If someone steals your passphrase-protected private key then if they figure out the passphrase (or if you didn't have one) then they can log in to any server that the public key was installed on, as you. As for sudo, you can remove sudo -H -u git and run that with su - git (give the password you created for the git user) then run gitosis-init < /path/to/public_key.pub but with this, you'll need to make sure the git user has permission to read the public key file. –  DerfK Mar 21 '11 at 23:31
Nice! That works. Turns out sudo wasn't installed on my cloud based server too. So the combo pack of installing that and your explanations really helped. Thank you much! –  user75295 Mar 21 '11 at 23:39
@user75295 I added an explanation of the "magic" behind the scenes between SSH and gitosis. –  DerfK Mar 21 '11 at 23:55

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.