On Mon, May 18, 2015 at 11:58:03AM +0100, John McIntyre wrote: > 2015-05-18 11:26 GMT+01:00 Heiko Voigt <hvoigt@xxxxxxxxxx>: > > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html