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.
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?
Thanks.
Heiko VoigtRe: Git Server Repository Security?
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. > > 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.
Cheers Heiko
[1] http://gitolite.com/gitolite/index.html
Re: Git Server Repository Security?
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. >> >> 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.
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..?
John.
Heiko VoigtRe: Git Server Repository Security?
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. > >> > >> 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.
Yes its a little more complex but not much.
> 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..?
No the repositories are only accessible by the defined groups/users.
The access control is done by the gitolite layer. It uses the command option in the authorized_keys file to restrict access. The access rights and groups and so on are configured in its own gitolite.conf file which is itself stored in a git repository in which you commit and push to change them (or add more ssh-keys).
It only uses ssh to authenticate the authorisation is then handled by the gitolite tool.
In my experience this is a setup simpler to handle then groups and users directly on the server. It also allows to give a unique url for accessing one repository. With multiple system users you would have one url per user per repository which is not nice when sharing these and breaks (or needs extra complexity) when using submodules.
Cheers Heiko
Re: Git Server Repository Security?
2015-05-18 12:57 GMT+01:00 Heiko Voigt <hvoigt@hvoigt.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. >> >> >> >> 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. > > Yes its a little more complex but not much. > >> 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..? > > No the repositories are only accessible by the defined groups/users. > > The access control is done by the gitolite layer. It uses the command > option in the authorized_keys file to restrict access. The access rights > and groups and so on are configured in its own gitolite.conf file which > is itself stored in a git repository in which you commit and push to > change them (or add more ssh-keys). > > It only uses ssh to authenticate the authorisation is then handled by > the gitolite tool. > > In my experience this is a setup simpler to handle then groups and users > directly on the server. It also allows to give a unique url for > accessing one repository. With multiple system users you would have one > url per user per repository which is not nice when sharing these and > breaks (or needs extra complexity) when using submodules.
All right, so I'm a bit confused. I followed the instructions to get gitolite, and put a public key, placing it on the server. I then run..
*** gitolite setup -pk server-git01_rsa.pub Initialized empty Git repository in /home/git/repositories/gitolite-admin.git/ Initialized empty Git repository in /home/git/repositories/testing.git/ ***
Our repositories are under /opt/git/n where n is the name of the repo.
Is there a config file where this is defined?
Heiko VoigtRe: Git Server Repository Security?
On Mon, May 18, 2015 at 01:32:07PM +0100, John McIntyre wrote:
> All right, so I'm a bit confused. I followed the instructions to get > gitolite, and put a public key, placing it on the server. I then > run.. > > *** > gitolite setup -pk server-git01_rsa.pub > Initialized empty Git repository in /home/git/repositories/gitolite-admin.git/ > Initialized empty Git repository in /home/git/repositories/testing.git/ > *** > > Our repositories are under /opt/git/n where n is the name of the repo. > > Is there a config file where this is defined?
I do not know, because I always used /home/git. In case not: How about just using a symlink? And there is a lot of information on google ;-)
Cheers Heiko
Re: Git Server Repository Security?
2015-05-18 13:39 GMT+01:00 Heiko Voigt <hvoigt@hvoigt.net>:
> On Mon, May 18, 2015 at 01:32:07PM +0100, John McIntyre wrote: >> All right, so I'm a bit confused. I followed the instructions to get >> gitolite, and put a public key, placing it on the server. I then >> run.. >> >> *** >> gitolite setup -pk server-git01_rsa.pub >> Initialized empty Git repository in /home/git/repositories/gitolite-admin.git/ >> Initialized empty Git repository in /home/git/repositories/testing.git/ >> *** >> >> Our repositories are under /opt/git/n where n is the name of the repo. >> >> Is there a config file where this is defined? > > I do not know, because I always used /home/git. In case not: How about > just using a symlink? And there is a lot of information on google ;-)
I'm confused. If I run the gitolite command again, in the /opt/git directory, will that set it up correctly?
And I thought that access was via key? In the example config files I've seen, there is no mention of different keys in the config file.
Our users can currently ssh into the box. I want to stop that, but since they all ssh in as the use 'git', if I change the shell of that user to /sbin/nologin or something similar, I'm effectively locking out the git user.
Kevin DaudtRe: Git Server Repository Security?
On Mon, May 18, 2015 at 04:07:49PM +0100, John McIntyre wrote:
> 2015-05-18 13:39 GMT+01:00 Heiko Voigt <hvoigt@hvoigt.net>: > > On Mon, May 18, 2015 at 01:32:07PM +0100, John McIntyre wrote: > > > > I do not know, because I always used /home/git. In case not: How about > > just using a symlink? And there is a lot of information on google ;-) > > > I'm confused. If I run the gitolite command again, in the /opt/git > directory, will that set it up correctly?
It's recommended to put it inside /home/git/, but if you want, you can set $REPO_BASE inside /home/git/.gitolite.rc
> > And I thought that access was via key? In the example config files > I've seen, there is no mention of different keys in the config file.
Yes, but these keys are managed through a special repository called gitolite-admin.git. You can add the keys to this repository and change the config to give people access. When you commit and push this repository, those changes come into effect.
> > Our users can currently ssh into the box. I want to stop that, but > since they all ssh in as the use 'git', if I change the shell of that > user to /sbin/nologin or something similar, I'm effectively locking > out the git user.
gitolite itself cares for that through the mechanism mentioned earlier. When you try to log in, gitolite takes over, lists the repositories you have access to, and then closes the connection, so no need to set login to /sbin/nologin.
Note that there is also git-shell, which is a shell which can only be used for git commands.
Sitaram ChamartyRe: Git Server Repository Security?
On 05/18/2015 06:02 PM, John McIntyre wrote:
> All right, so I'm a bit confused. I followed the instructions to get > gitolite, and put a public key, placing it on the server. I then > run.. > > *** > gitolite setup -pk server-git01_rsa.pub > Initialized empty Git repository in /home/git/repositories/gitolite-admin.git/ > Initialized empty Git repository in /home/git/repositories/testing.git/ > *** > > Our repositories are under /opt/git/n where n is the name of the repo.
Just use a symlink. Move ~/repositories to wherever you want and then create a symlink at ~/repositories that points there.
Apologies for replying to some of your other message here, but do not use /bin/nologin as the shell. It needs to be something that can take "-c" parameter, so not even git-shell will work. Since all access is controlled by the forced command in the authkeys file, this is not an issue so just use bash or sh or whatever.
sitaram
Re: Git Server Repository Security?
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
Sitaram ChamartyRe: Git Server Repository Security?
On 05/18/2015 04:28 PM, John McIntyre wrote:
> 2015-05-18 11:26 GMT+01:00 Heiko Voigt <hvoigt@hvoigt.net>:
>> 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. > > 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..?
My usual answer to this is http://gitolite.com/gitolite/overview.html#basic-use-case
The first example is doable with file system permissions if you give everyone a separate userid, but it's a nightmare. The second one is not even possible.