I'd like to set up a git server over ssh, with a single SSH account for the project. All project members should have their ssh keys listed in authorized_keys. Lockdown should restrict access to only doing git stuff, and only inside a dedicated directory.

What is the best way to create such a setup? There is git-shell, which apparently can do the lock-down to only doing git commands, but I can't find out how to restrict access to a single directory. There are also various Python and Ruby wrappers - which of these should I trust?


you could have a look at gitosis or gitolite, gitolite is kind of better in respect of granting access and so on to repositories, you wouldnt have to worry about giving users access to the server and what not either

  • So what should I put into authorized_keys when using gitolite? – Martin v. Löwis Jan 23 '10 at 23:52
  • Your server will run gitolite/gitosis (gitolite is basically the same as gitosis in its code base it just adds the functionality to apply more restrictions to the repos) which will have one user (git) to allow it to run on the system. You will configure users through the gitosis.conf file allowing them access to the repositories they need access to and not to others. If your having trouble have a look at this nfocipher.com/… which will guide you through gitosis setup and user setup as well or comment with specific issues.......... – seanl Jan 25 '10 at 13:23

What's your threat model?

Good guy accidentally destroys git repository or other data: Make sure your users can only write to their homedir, tmp and the git repository. Back up the repository after every commit and practice recovery procedures regularly.

Bad guy steals someone's private key and wants to own your system: Your attack surface is limited to parts of sshd protected by authentication - and whatever shell interface you use, so make it as small as possible. Python/Ruby wrappers involve a lot of code, and a lot of room for errors. Use the git-shell or consider using the Match and ChrootDirectory directives in sshd_config to limit which parts of the filesystem the users can access.

Bad guy steals someone's private key and gets your source code: Teach users how to protect their private keys and establish procedures for revoking keys fast (e.g. who to call at 4am to have keys revoked).

Don't use .ssh/authorized_keys, instead use the AuthorizedKeyfile keyword in sshd_config to specify a path were users don't have write access, e.g. /etc/ssh/keys/%u. It's too hard to make sure users will never be able to overwrite .ssh/authorized_keys with their own copy.

Also, keep the user keyfiles and sshd_config version-controlled as to allow audits.

  • The threat model is different: bad guy has access to repository a, and can use that to read other files (outside of the repository). I fail to see the problem auth authorized_keys: it's a threat already if the user is able to write the file. The user shouldn't be able to write any files outside of the repository. – Martin v. Löwis Jan 23 '10 at 23:55
  • Then sshd's ChrootDirectory feature is your friend, but creating a chroot environment is not a trivial thing to do. I'm curious why it would be a security threat if the user is able to read other files on your system. Use standard filesystem permissions to make sure private files are unavailable. – Alex Holst Jan 24 '10 at 9:47
  • Subversion (svnserve) has a feature where it restricts itself to a certain directory, even without chroot. Basically, I'm looking for something like this with git - because I don't trust myself to set all file permissions adequately (I'll try to, but I don't want to constantly audit the system to find out whether permissions are still correct). – Martin v. Löwis Jan 24 '10 at 10:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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