All of lore.kernel.org
 help / color / mirror / Atom feed
* Git Server Repository Security?
@ 2015-05-18 10:07 John McIntyre
  2015-05-18 10:26 ` Heiko Voigt
  0 siblings, 1 reply; 11+ messages in thread
From: John McIntyre @ 2015-05-18 10:07 UTC (permalink / raw)
  To: git

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.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Git Server Repository Security?
  2015-05-18 10:07 Git Server Repository Security? John McIntyre
@ 2015-05-18 10:26 ` Heiko Voigt
  2015-05-18 10:58   ` John McIntyre
  0 siblings, 1 reply; 11+ messages in thread
From: Heiko Voigt @ 2015-05-18 10:26 UTC (permalink / raw)
  To: John McIntyre; +Cc: git

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Git Server Repository Security?
  2015-05-18 10:26 ` Heiko Voigt
@ 2015-05-18 10:58   ` John McIntyre
  2015-05-18 11:57     ` Heiko Voigt
                       ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: John McIntyre @ 2015-05-18 10:58 UTC (permalink / raw)
  To: Heiko Voigt; +Cc: git

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.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Git Server Repository Security?
  2015-05-18 10:58   ` John McIntyre
@ 2015-05-18 11:57     ` Heiko Voigt
  2015-05-18 12:32       ` John McIntyre
  2015-05-18 12:18     ` Jason Cooper
  2015-05-19  0:41     ` Sitaram Chamarty
  2 siblings, 1 reply; 11+ messages in thread
From: Heiko Voigt @ 2015-05-18 11:57 UTC (permalink / raw)
  To: John McIntyre; +Cc: git

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Git Server Repository Security?
  2015-05-18 10:58   ` John McIntyre
  2015-05-18 11:57     ` Heiko Voigt
@ 2015-05-18 12:18     ` Jason Cooper
  2015-05-19  0:41     ` Sitaram Chamarty
  2 siblings, 0 replies; 11+ messages in thread
From: Jason Cooper @ 2015-05-18 12:18 UTC (permalink / raw)
  To: John McIntyre; +Cc: Heiko Voigt, git

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Git Server Repository Security?
  2015-05-18 11:57     ` Heiko Voigt
@ 2015-05-18 12:32       ` John McIntyre
  2015-05-18 12:39         ` Heiko Voigt
  2015-05-19  0:35         ` Sitaram Chamarty
  0 siblings, 2 replies; 11+ messages in thread
From: John McIntyre @ 2015-05-18 12:32 UTC (permalink / raw)
  To: Heiko Voigt; +Cc: git

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?

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Git Server Repository Security?
  2015-05-18 12:32       ` John McIntyre
@ 2015-05-18 12:39         ` Heiko Voigt
  2015-05-18 15:07           ` John McIntyre
  2015-05-19  0:35         ` Sitaram Chamarty
  1 sibling, 1 reply; 11+ messages in thread
From: Heiko Voigt @ 2015-05-18 12:39 UTC (permalink / raw)
  To: John McIntyre; +Cc: git

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Git Server Repository Security?
  2015-05-18 12:39         ` Heiko Voigt
@ 2015-05-18 15:07           ` John McIntyre
  2015-05-18 19:15             ` Kevin Daudt
  0 siblings, 1 reply; 11+ messages in thread
From: John McIntyre @ 2015-05-18 15:07 UTC (permalink / raw)
  To: Heiko Voigt; +Cc: git

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.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Git Server Repository Security?
  2015-05-18 15:07           ` John McIntyre
@ 2015-05-18 19:15             ` Kevin Daudt
  0 siblings, 0 replies; 11+ messages in thread
From: Kevin Daudt @ 2015-05-18 19:15 UTC (permalink / raw)
  To: John McIntyre; +Cc: Heiko Voigt, git

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.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Git Server Repository Security?
  2015-05-18 12:32       ` John McIntyre
  2015-05-18 12:39         ` Heiko Voigt
@ 2015-05-19  0:35         ` Sitaram Chamarty
  1 sibling, 0 replies; 11+ messages in thread
From: Sitaram Chamarty @ 2015-05-19  0:35 UTC (permalink / raw)
  To: John McIntyre, Heiko Voigt; +Cc: git

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Git Server Repository Security?
  2015-05-18 10:58   ` John McIntyre
  2015-05-18 11:57     ` Heiko Voigt
  2015-05-18 12:18     ` Jason Cooper
@ 2015-05-19  0:41     ` Sitaram Chamarty
  2 siblings, 0 replies; 11+ messages in thread
From: Sitaram Chamarty @ 2015-05-19  0:41 UTC (permalink / raw)
  To: John McIntyre, Heiko Voigt; +Cc: git

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.

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2015-05-19  0:41 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-05-18 10:07 Git Server Repository Security? John McIntyre
2015-05-18 10:26 ` Heiko Voigt
2015-05-18 10:58   ` John McIntyre
2015-05-18 11:57     ` Heiko Voigt
2015-05-18 12:32       ` John McIntyre
2015-05-18 12:39         ` Heiko Voigt
2015-05-18 15:07           ` John McIntyre
2015-05-18 19:15             ` Kevin Daudt
2015-05-19  0:35         ` Sitaram Chamarty
2015-05-18 12:18     ` Jason Cooper
2015-05-19  0:41     ` Sitaram Chamarty

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.