{"thread":{"id":"39351","subject":"Git Server Repository Security?","startedAt":"2015-05-18T10:07:02Z","lastAt":"2015-05-19T00:41:44Z","messageCount":11,"participants":["John McIntyre","Heiko Voigt","Jason Cooper","Kevin Daudt","Sitaram Chamarty"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"261419","messageId":"CABQ4iYiWu17H1XhPYebmP27x=R11SKW0P91AW2y9S=r-2c0B1A@mail.gmail.com","threadId":"39351","inReplyTo":null,"subject":"Git Server Repository Security?","fromName":"John McIntyre","fromEmail":"joh98.mac@gmail.com","sentAt":"2015-05-18T10:07:02Z","receivedAt":"2015-05-18T10:07:02Z","isPatch":false,"sender":{"key":"joh98.mac@gmail.com","avatar":null},"body":"Hi,\nI've been asked to set up a git repository for a few projects.  So I\nhave a Linux CentOS server running git.   I place the repositories\nunder /opt and I use the .ssh/authorized_keys of the git user, to\ngrant access. The user sends me his private key, and I paste it into\nthe end of the file.\n\nAnd now, I realise that there's a problem.  If I have /opt/repo1.git\nand /opt/repo2.git, then all users can access both repositories.\n\nIs there a way to prevent this?\n\nThanks.\n"},{"id":"261420","messageId":"20150518102633.GA15186@book.hvoigt.net","threadId":"39351","inReplyTo":"CABQ4iYiWu17H1XhPYebmP27x=R11SKW0P91AW2y9S=r-2c0B1A@mail.gmail.com","subject":"Re: Git Server Repository Security?","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2015-05-18T10:26:33Z","receivedAt":"2015-05-18T10:26:33Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Mon, May 18, 2015 at 11:07:02AM +0100, John McIntyre wrote:\n> Hi,\n> I've been asked to set up a git repository for a few projects.  So I\n> have a Linux CentOS server running git.   I place the repositories\n> under /opt and I use the .ssh/authorized_keys of the git user, to\n> grant access. The user sends me his private key, and I paste it into\n> the end of the file.\n> \n> And now, I realise that there's a problem.  If I have /opt/repo1.git\n> and /opt/repo2.git, then all users can access both repositories.\n> \n> Is there a way to prevent this?\n\nIf you want a simple tool using ssh-keys have a look at gitolite[1].\nIt quite simple to setup and with it you can specify all kinds of access\nrights.\n\nCheers Heiko\n\n[1] http://gitolite.com/gitolite/index.html\n"},{"id":"261421","messageId":"CABQ4iYgjtdw46Psow_e7uGLqx0ZiFt+TQOgXvCmP1-W10LGEmg@mail.gmail.com","threadId":"39351","inReplyTo":"20150518102633.GA15186@book.hvoigt.net","subject":"Re: Git Server Repository Security?","fromName":"John McIntyre","fromEmail":"joh98.mac@gmail.com","sentAt":"2015-05-18T10:58:03Z","receivedAt":"2015-05-18T10:58:03Z","isPatch":false,"sender":{"key":"joh98.mac@gmail.com","avatar":null},"body":"2015-05-18 11:26 GMT+01:00 Heiko Voigt <hvoigt@hvoigt.net>:\n> Hi,\n>\n> On Mon, May 18, 2015 at 11:07:02AM +0100, John McIntyre wrote:\n>> Hi,\n>> I've been asked to set up a git repository for a few projects.  So I\n>> have a Linux CentOS server running git.   I place the repositories\n>> under /opt and I use the .ssh/authorized_keys of the git user, to\n>> grant access. The user sends me his private key, and I paste it into\n>> the end of the file.\n>>\n>> And now, I realise that there's a problem.  If I have /opt/repo1.git\n>> and /opt/repo2.git, then all users can access both repositories.\n>>\n>> Is there a way to prevent this?\n>\n> If you want a simple tool using ssh-keys have a look at gitolite[1].\n> It quite simple to setup and with it you can specify all kinds of access\n> rights.\n\nThat's adding a separate level of complexity.\n\nI looked into filesystem-level permissions.  I don't see any means of\ndoing so, because everyone accesses the repositories using the 'git'\nuser.  So even if I add a group like 'devClient1' and then change the\ngroup ownership of a repo to that user, they'll still be able to\naccess all repos..?\n\nJohn.\n"},{"id":"261422","messageId":"20150518115749.GA16841@book.hvoigt.net","threadId":"39351","inReplyTo":"CABQ4iYgjtdw46Psow_e7uGLqx0ZiFt+TQOgXvCmP1-W10LGEmg@mail.gmail.com","subject":"Re: Git Server Repository Security?","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2015-05-18T11:57:49Z","receivedAt":"2015-05-18T11:57:49Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Mon, May 18, 2015 at 11:58:03AM +0100, John McIntyre wrote:\n> 2015-05-18 11:26 GMT+01:00 Heiko Voigt <hvoigt@hvoigt.net>:\n> > Hi,\n> >\n> > On Mon, May 18, 2015 at 11:07:02AM +0100, John McIntyre wrote:\n> >> Hi,\n> >> I've been asked to set up a git repository for a few projects.  So I\n> >> have a Linux CentOS server running git.   I place the repositories\n> >> under /opt and I use the .ssh/authorized_keys of the git user, to\n> >> grant access. The user sends me his private key, and I paste it into\n> >> the end of the file.\n> >>\n> >> And now, I realise that there's a problem.  If I have /opt/repo1.git\n> >> and /opt/repo2.git, then all users can access both repositories.\n> >>\n> >> Is there a way to prevent this?\n> >\n> > If you want a simple tool using ssh-keys have a look at gitolite[1].\n> > It quite simple to setup and with it you can specify all kinds of access\n> > rights.\n> \n> That's adding a separate level of complexity.\n\nYes its a little more complex but not much.\n\n> I looked into filesystem-level permissions.  I don't see any means of\n> doing so, because everyone accesses the repositories using the 'git'\n> user.  So even if I add a group like 'devClient1' and then change the\n> group ownership of a repo to that user, they'll still be able to\n> access all repos..?\n\nNo the repositories are only accessible by the defined groups/users.\n\nThe access control is done by the gitolite layer. It uses the command\noption in the authorized_keys file to restrict access. The access rights\nand groups and so on are configured in its own gitolite.conf file which\nis itself stored in a git repository in which you commit and push to\nchange them (or add more ssh-keys).\n\nIt only uses ssh to authenticate the authorisation is then handled by\nthe gitolite tool.\n\nIn my experience this is a setup simpler to handle then groups and users\ndirectly on the server. It also allows to give a unique url for\naccessing one repository. With multiple system users you would have one\nurl per user per repository which is not nice when sharing these and\nbreaks (or needs extra complexity) when using submodules.\n\nCheers Heiko\n"},{"id":"261425","messageId":"20150518121805.GA29057@io.lakedaemon.net","threadId":"39351","inReplyTo":"CABQ4iYgjtdw46Psow_e7uGLqx0ZiFt+TQOgXvCmP1-W10LGEmg@mail.gmail.com","subject":"Re: Git Server Repository Security?","fromName":"Jason Cooper","fromEmail":"git@lakedaemon.net","sentAt":"2015-05-18T12:18:05Z","receivedAt":"2015-05-18T12:18:05Z","isPatch":false,"sender":{"key":"git@lakedaemon.net","avatar":null},"body":"On Mon, May 18, 2015 at 11:58:03AM +0100, John McIntyre wrote:\n> 2015-05-18 11:26 GMT+01:00 Heiko Voigt <hvoigt@hvoigt.net>:\n> > Hi,\n> >\n> > On Mon, May 18, 2015 at 11:07:02AM +0100, John McIntyre wrote:\n> >> Hi,\n> >> I've been asked to set up a git repository for a few projects.  So I\n> >> have a Linux CentOS server running git.   I place the repositories\n> >> under /opt and I use the .ssh/authorized_keys of the git user, to\n> >> grant access. The user sends me his private key, and I paste it into\n> >> the end of the file.\n\nI _hope_ you meant 'public' key here. ;-)\n\n> >> And now, I realise that there's a problem.  If I have /opt/repo1.git\n> >> and /opt/repo2.git, then all users can access both repositories.\n> >>\n> >> Is there a way to prevent this?\n> >\n> > If you want a simple tool using ssh-keys have a look at gitolite[1].\n> > It quite simple to setup and with it you can specify all kinds of access\n> > rights.\n> \n> That's adding a separate level of complexity.\n\nWhat you're asking for is going to a require *some* additional\ncomplexity.\n\n> I looked into filesystem-level permissions.  I don't see any means of\n> doing so, because everyone accesses the repositories using the 'git'\n> user.  So even if I add a group like 'devClient1' and then change the\n> group ownership of a repo to that user, they'll still be able to\n> access all repos..?\n\nThe github/Atlassian workflow isn't the only way to skin the cat. :)\n\nIt sounds to me like you want users to git+ssh into with their own user\naccts.  Then you can leverage the posix permissions model.\nUnfortunately, without a bit a restriction, you'll also be granting each\nof them a user shell on the git server.  You may not want that.\n\nThere are many low-level ways to accomplish this, depending on the\nmaintenance burden you are willing to take on.  If the server is\nInternet-accessible will also affect what you are willing to tolerate.\n\nMost of the solutions you may be interested in will involve ssh\nsingle-purpose keys.  Basically, pre-pending the public key in the\n~/.ssh/authorized_keys file with 'command=/path/to/allowed/cmd ...'.\nUsers attempting to ssh in to that user acct will *only* be allowed to\nexecute that command.  The command can be a filter for the\nuser-requested command, held in the environment var,\nSSH_ORIGINAL_COMMAND.\n\nFor an example of one way to leverage this, see some code I wrote to\nallow passwordless (cronjob) git and rsync ssh commands:\n\n  http://git.infradead.org/users/jcooper/secsh.git/blob/HEAD:/README\n\nsecsh's big drawback is that if the restricted public key is the only\none granting them access to the git server, the user has no way to\nadd/delete git repos.  For your usecase, that may not be important.\n\nShould you consider deploying secsh, you may also want this [1] patch\nfor openssh that adds a 'no-user-shell' option for the ssh public key\nrestrictions.  With that enabled, no shell is executed on the box,\nsignificantly limiting damage caused by a stolen user ssh key.  Yes,\nI've been meaning to submit it.  -ETIME and whatnot.  It probably needs\nupdated in order to apply cleanly.\n\nhth,\n\nJason.\n\n[1] http://www.openwall.com/lists/oss-security/2014/09/25/41\n"},{"id":"261424","messageId":"CABQ4iYjwa-KmZAQV=p5efQYBZu3ymQRNwTC4TGXdpo4groArCA@mail.gmail.com","threadId":"39351","inReplyTo":"20150518115749.GA16841@book.hvoigt.net","subject":"Re: Git Server Repository Security?","fromName":"John McIntyre","fromEmail":"joh98.mac@gmail.com","sentAt":"2015-05-18T12:32:07Z","receivedAt":"2015-05-18T12:32:07Z","isPatch":false,"sender":{"key":"joh98.mac@gmail.com","avatar":null},"body":"2015-05-18 12:57 GMT+01:00 Heiko Voigt <hvoigt@hvoigt.net>:\n> On Mon, May 18, 2015 at 11:58:03AM +0100, John McIntyre wrote:\n>> 2015-05-18 11:26 GMT+01:00 Heiko Voigt <hvoigt@hvoigt.net>:\n>> > Hi,\n>> >\n>> > On Mon, May 18, 2015 at 11:07:02AM +0100, John McIntyre wrote:\n>> >> Hi,\n>> >> I've been asked to set up a git repository for a few projects.  So I\n>> >> have a Linux CentOS server running git.   I place the repositories\n>> >> under /opt and I use the .ssh/authorized_keys of the git user, to\n>> >> grant access. The user sends me his private key, and I paste it into\n>> >> the end of the file.\n>> >>\n>> >> And now, I realise that there's a problem.  If I have /opt/repo1.git\n>> >> and /opt/repo2.git, then all users can access both repositories.\n>> >>\n>> >> Is there a way to prevent this?\n>> >\n>> > If you want a simple tool using ssh-keys have a look at gitolite[1].\n>> > It quite simple to setup and with it you can specify all kinds of access\n>> > rights.\n>>\n>> That's adding a separate level of complexity.\n>\n> Yes its a little more complex but not much.\n>\n>> I looked into filesystem-level permissions.  I don't see any means of\n>> doing so, because everyone accesses the repositories using the 'git'\n>> user.  So even if I add a group like 'devClient1' and then change the\n>> group ownership of a repo to that user, they'll still be able to\n>> access all repos..?\n>\n> No the repositories are only accessible by the defined groups/users.\n>\n> The access control is done by the gitolite layer. It uses the command\n> option in the authorized_keys file to restrict access. The access rights\n> and groups and so on are configured in its own gitolite.conf file which\n> is itself stored in a git repository in which you commit and push to\n> change them (or add more ssh-keys).\n>\n> It only uses ssh to authenticate the authorisation is then handled by\n> the gitolite tool.\n>\n> In my experience this is a setup simpler to handle then groups and users\n> directly on the server. It also allows to give a unique url for\n> accessing one repository. With multiple system users you would have one\n> url per user per repository which is not nice when sharing these and\n> breaks (or needs extra complexity) when using submodules.\n\nAll right, so I'm a bit confused.  I followed the instructions to get\ngitolite, and put a public key, placing it on the server.  I then\nrun..\n\n***\ngitolite setup -pk server-git01_rsa.pub\nInitialized empty Git repository in /home/git/repositories/gitolite-admin.git/\nInitialized empty Git repository in /home/git/repositories/testing.git/\n***\n\nOur repositories are under /opt/git/n where n is the name of the repo.\n\nIs there a config file where this is defined?\n"},{"id":"261426","messageId":"20150518123948.GA17075@book.hvoigt.net","threadId":"39351","inReplyTo":"CABQ4iYjwa-KmZAQV=p5efQYBZu3ymQRNwTC4TGXdpo4groArCA@mail.gmail.com","subject":"Re: Git Server Repository Security?","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2015-05-18T12:39:49Z","receivedAt":"2015-05-18T12:39:49Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Mon, May 18, 2015 at 01:32:07PM +0100, John McIntyre wrote:\n> All right, so I'm a bit confused.  I followed the instructions to get\n> gitolite, and put a public key, placing it on the server.  I then\n> run..\n> \n> ***\n> gitolite setup -pk server-git01_rsa.pub\n> Initialized empty Git repository in /home/git/repositories/gitolite-admin.git/\n> Initialized empty Git repository in /home/git/repositories/testing.git/\n> ***\n> \n> Our repositories are under /opt/git/n where n is the name of the repo.\n> \n> Is there a config file where this is defined?\n\nI do not know, because I always used /home/git. In case not: How about\njust using a symlink? And there is a lot of information on google ;-)\n\nCheers Heiko\n"},{"id":"261456","messageId":"CABQ4iYgauiENEv5ESbJTgUWVhRjt3NxmJfxTZTaa8U072atDEQ@mail.gmail.com","threadId":"39351","inReplyTo":"20150518123948.GA17075@book.hvoigt.net","subject":"Re: Git Server Repository Security?","fromName":"John McIntyre","fromEmail":"joh98.mac@gmail.com","sentAt":"2015-05-18T15:07:49Z","receivedAt":"2015-05-18T15:07:49Z","isPatch":false,"sender":{"key":"joh98.mac@gmail.com","avatar":null},"body":"2015-05-18 13:39 GMT+01:00 Heiko Voigt <hvoigt@hvoigt.net>:\n> On Mon, May 18, 2015 at 01:32:07PM +0100, John McIntyre wrote:\n>> All right, so I'm a bit confused.  I followed the instructions to get\n>> gitolite, and put a public key, placing it on the server.  I then\n>> run..\n>>\n>> ***\n>> gitolite setup -pk server-git01_rsa.pub\n>> Initialized empty Git repository in /home/git/repositories/gitolite-admin.git/\n>> Initialized empty Git repository in /home/git/repositories/testing.git/\n>> ***\n>>\n>> Our repositories are under /opt/git/n where n is the name of the repo.\n>>\n>> Is there a config file where this is defined?\n>\n> I do not know, because I always used /home/git. In case not: How about\n> just using a symlink? And there is a lot of information on google ;-)\n\n\nI'm confused.   If I run the gitolite command again, in the /opt/git\ndirectory, will that set it up correctly?\n\nAnd I thought that access was via key?  In the example config files\nI've seen, there is no mention of different keys in the config file.\n\nOur users can currently ssh into the box.  I want to stop that, but\nsince they all ssh in as the use 'git', if I change the shell of that\nuser to /sbin/nologin or something similar, I'm effectively locking\nout the git user.\n"},{"id":"261497","messageId":"20150518191555.GA27248@vps892.directvps.nl","threadId":"39351","inReplyTo":"CABQ4iYgauiENEv5ESbJTgUWVhRjt3NxmJfxTZTaa8U072atDEQ@mail.gmail.com","subject":"Re: Git Server Repository Security?","fromName":"Kevin Daudt","fromEmail":"me@ikke.info","sentAt":"2015-05-18T19:15:55Z","receivedAt":"2015-05-18T19:15:55Z","isPatch":false,"sender":{"key":"me@ikke.info","avatar":"https://avatars.githubusercontent.com/u/135698?v=4"},"body":"On Mon, May 18, 2015 at 04:07:49PM +0100, John McIntyre wrote:\n> 2015-05-18 13:39 GMT+01:00 Heiko Voigt <hvoigt@hvoigt.net>:\n> > On Mon, May 18, 2015 at 01:32:07PM +0100, John McIntyre wrote:\n> >\n> > I do not know, because I always used /home/git. In case not: How about\n> > just using a symlink? And there is a lot of information on google ;-)\n> \n> \n> I'm confused.   If I run the gitolite command again, in the /opt/git\n> directory, will that set it up correctly?\n\nIt's recommended to put it inside /home/git/, but if you want, you can\nset $REPO_BASE inside /home/git/.gitolite.rc\n\n> \n> And I thought that access was via key?  In the example config files\n> I've seen, there is no mention of different keys in the config file.\n\nYes, but these keys are managed through a special repository called\ngitolite-admin.git. You can add the keys to this repository and change\nthe config to give people access. When you commit and push this\nrepository, those changes come into effect.\n\n> \n> Our users can currently ssh into the box.  I want to stop that, but\n> since they all ssh in as the use 'git', if I change the shell of that\n> user to /sbin/nologin or something similar, I'm effectively locking\n> out the git user.\n\ngitolite itself cares for that through the mechanism mentioned earlier.\nWhen you try to log in, gitolite takes over, lists the repositories you\nhave access to, and then closes the connection, so no need to set login\nto /sbin/nologin.\n\nNote that there is also git-shell, which is a shell which can only be\nused for git commands.\n"},{"id":"261528","messageId":"555A8569.30607@gmail.com","threadId":"39351","inReplyTo":"CABQ4iYjwa-KmZAQV=p5efQYBZu3ymQRNwTC4TGXdpo4groArCA@mail.gmail.com","subject":"Re: Git Server Repository Security?","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2015-05-19T00:35:53Z","receivedAt":"2015-05-19T00:35:53Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 05/18/2015 06:02 PM, John McIntyre wrote:\n\n> All right, so I'm a bit confused.  I followed the instructions to get\n> gitolite, and put a public key, placing it on the server.  I then\n> run..\n> \n> ***\n> gitolite setup -pk server-git01_rsa.pub\n> Initialized empty Git repository in /home/git/repositories/gitolite-admin.git/\n> Initialized empty Git repository in /home/git/repositories/testing.git/\n> ***\n> \n> Our repositories are under /opt/git/n where n is the name of the repo.\n\nJust use a symlink.  Move ~/repositories to wherever you want and then\ncreate a symlink at ~/repositories that points there.\n\nApologies for replying to some of your other message here, but\ndo not use /bin/nologin as the shell.  It needs to be something that can\ntake \"-c\" parameter, so not even git-shell will work.  Since all access\nis controlled by the forced command in the authkeys file, this is not an\nissue so just use bash or sh or whatever.\n\nsitaram\n"},{"id":"261529","messageId":"555A86C8.2020006@gmail.com","threadId":"39351","inReplyTo":"CABQ4iYgjtdw46Psow_e7uGLqx0ZiFt+TQOgXvCmP1-W10LGEmg@mail.gmail.com","subject":"Re: Git Server Repository Security?","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2015-05-19T00:41:44Z","receivedAt":"2015-05-19T00:41:44Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 05/18/2015 04:28 PM, John McIntyre wrote:\n> 2015-05-18 11:26 GMT+01:00 Heiko Voigt <hvoigt@hvoigt.net>:\n\n>> If you want a simple tool using ssh-keys have a look at gitolite[1].\n>> It quite simple to setup and with it you can specify all kinds of access\n>> rights.\n> \n> That's adding a separate level of complexity.\n> \n> I looked into filesystem-level permissions.  I don't see any means of\n> doing so, because everyone accesses the repositories using the 'git'\n> user.  So even if I add a group like 'devClient1' and then change the\n> group ownership of a repo to that user, they'll still be able to\n> access all repos..?\n\nMy usual answer to this is http://gitolite.com/gitolite/overview.html#basic-use-case\n\nThe first example is doable with file system permissions if you give\neveryone a separate userid, but it's a nightmare.  The second one is not\neven possible.\n"}]}