So we took on some vendors to help us out. I wanted to provide these individuals authenticated, read-only access to our git repos so they could stay current with the project, but not commit code directly (they’ll have their own repo). Google yielded these excellent results pages.

When read altogether, I had a few options.

  1. Run the git-daemon. The repo would be publicy available over the internet via the git (git://) protocol.  This provides read-only access, but it provides it to the whole world.  Not a solution.
  2. Run a GitHub-like server, like Gitosis or Gitolite.  This was the sledgehammer solution.  Fine-grained access control, plus all the other bells and whistles. But I was not interested in installing and understanding a whole git-hosting server application.
  3. SSH via git-shell.  Each user gets a regular SSH account on the server, but each user gets a git-shell instead of a regular login shell like bash. The git-shell restricts the user to git operations.  Write permissions are restricted using standard Linux permissions on the repo itself.

So #3 was what I needed. I created an SSH login for each user that needed access to the repo. I set the login shell for each user to /usr/bin/git-shell. I put each user in a group that had read-only file system permissions to the repo.  Testing it out worked well.  Users could git clone and pull, but pushing failed and attempting to SSH directly failed.

One last note: as the man page mentions, you can create a directory called git-shell-commands in home directories of git-shell users.  git-shell users will be able to run any command in this directory.  If there is a help program in the directory, it is run when a git-shell user logs in.  More details on git-shell-commands here, including the location of sample git-shell commands on your server.