Re: Git Server Repository Security?

[Jason Cooper <git@lakedaemon.net>]

On Mon, May 18, 2015 at 11:58:03AM +0100, John McIntyre wrote:
> 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. ;-)

> >> 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.

> 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