Re: Git Server Repository Security?

From: Jason Cooper <git@lakedaemon.net>
Date: May 18, 2015, 12:18 UTC
Message-ID: <20150518121805.GA29057@io.lakedaemon.net>
In-Reply-To: <CABQ4iYgjtdw46Psow_e7uGLqx0ZiFt+TQOgXvCmP1-W10LGEmg@mail.gmail.com>

On Mon, May 18, 2015 at 11:58:03AM +0100, John McIntyre wrote:

Show 10 quoted lines

> 2015-05-18 11:26 GMT+01:00 Heiko Voigt <hvoigt@hvoigt.net>:
> > Hi,
> >
> > On Mon, May 18, 2015 at 11:07:02AM +0100, John McIntyre wrote:
> >> Hi,
> >> I've been asked to set up a git repository for a few projects.  So I
> >> have a Linux CentOS server running git.   I place the repositories
> >> under /opt and I use the .ssh/authorized_keys of the git user, to
> >> grant access. The user sends me his private key, and I paste it into
> >> the end of the file.

I _hope_ you meant 'public' key here. ;-)

Show 10 quoted lines

> >> And now, I realise that there's a problem.  If I have /opt/repo1.git
> >> and /opt/repo2.git, then all users can access both repositories.
> >>
> >> Is there a way to prevent this?
> >
> > If you want a simple tool using ssh-keys have a look at gitolite[1].
> > It quite simple to setup and with it you can specify all kinds of access
> > rights.
> 
> That's adding a separate level of complexity.

What you're asking for is going to a require *some* additional complexity.

Show 5 quoted lines

> I looked into filesystem-level permissions.  I don't see any means of
> doing so, because everyone accesses the repositories using the 'git'
> user.  So even if I add a group like 'devClient1' and then change the
> group ownership of a repo to that user, they'll still be able to
> access all repos..?

The github/Atlassian workflow isn't the only way to skin the cat. :)

It sounds to me like you want users to git+ssh into with their own user accts. Then you can leverage the posix permissions model. Unfortunately, without a bit a restriction, you'll also be granting each of them a user shell on the git server. You may not want that.

There are many low-level ways to accomplish this, depending on the maintenance burden you are willing to take on. If the server is Internet-accessible will also affect what you are willing to tolerate.

Most of the solutions you may be interested in will involve ssh single-purpose keys. Basically, pre-pending the public key in the ~/.ssh/authorized_keys file with 'command=/path/to/allowed/cmd ...'. Users attempting to ssh in to that user acct will *only* be allowed to execute that command. The command can be a filter for the user-requested command, held in the environment var, SSH_ORIGINAL_COMMAND.

For an example of one way to leverage this, see some code I wrote to allow passwordless (cronjob) git and rsync ssh commands:

  http://git.infradead.org/users/jcooper/secsh.git/blob/HEAD:/README

secsh's big drawback is that if the restricted public key is the only one granting them access to the git server, the user has no way to add/delete git repos. For your usecase, that may not be important.

Should you consider deploying secsh, you may also want this [1] patch for openssh that adds a 'no-user-shell' option for the ssh public key restrictions. With that enabled, no shell is executed on the box, significantly limiting damage caused by a stolen user ssh key. Yes, I've been meaning to submit it. -ETIME and whatnot. It probably needs updated in order to apply cleanly.

hth,

Jason.

[1] http://www.openwall.com/lists/oss-security/2014/09/25/41