ldap/ad + gitolite + web

16 views
Skip to first unread message

Wim Bertels

unread,
Sep 19, 2024, 8:13:39 AM9/19/24
to gito...@googlegroups.com
Hello,

i have looked around for a setup for this,
if you know of a good instruction guide,
let me know

the goal is to setup a git server where many users can access their git
repositories, the authentication should be done by a remote ad/ldap
server, the authorization as to who can access which repository by
gitolite? (Since this also concerns many students with many different
repositories, i wonder if this is practically feasible and manageable
with gitolite? 1K+users and repositories. Or would you choose a
different path for setting up a stable git+web in this context)
The repository should also be accessible via https for browsing,
after authentication, i guess htpasswd. The goal is also to have a
stable setup in maintenance for several years, decades preferably.

I came accross this old info:
https://github.com/tillsteinbach/gitolite-ldap-config

Any feedback is appreciated,
Wi

Ken Hornstein

unread,
Sep 19, 2024, 8:36:07 AM9/19/24
to Wim Bertels, gito...@googlegroups.com
>the goal is to setup a git server where many users can access their git
>repositories, the authentication should be done by a remote ad/ldap
>server, the authorization as to who can access which repository by
>gitolite?

Exactly WHAT ssh protocol are you going to use for authentication when
you say you want to use "remote ad/ldap" for authentication? Because
the answer to that question really drives everything else.
That looks like the intent is for people to use password authentication
over ssh, and I presume that password is verified using the
aforementioned LDAP server. My personal concern with that issue is
if you're using git submodules the git URL is embedded inside of the
repository and people using the "username@gitserver" style URLs would
break with that. If you don't use submodules this is not a concern.

I will note that the security on the above setup depends on a script
(the "gitolite-shell-force-noninteractive.sh" script) that looks
trivial to defeat.

Sadly, given the modern Internet I doubt having a "stable" setup for
years, much less decades, is feasible. The constant battle of
security marches on.

--Ken

Wim Bertels

unread,
Sep 19, 2024, 9:47:57 AM9/19/24
to ke...@pobox.com, gito...@googlegroups.com
Ken Hornstein schreef op do 19-09-2024 om 08:36 [-0400]:
> [U ontvangt vaak geen e-mail van ke...@pobox.com. Informatie over
> waarom dit belangrijk is op
> https://aka.ms/LearnAboutSenderIdentification]
>
> > the goal is to setup a git server where many users can access their
> > git
> > repositories, the authentication should be done by a remote ad/ldap
> > server, the authorization as to who can access which repository by
> > gitolite?
>
> Exactly WHAT ssh protocol are you going to use for authentication
> when
> you say you want to use "remote ad/ldap" for authentication? Because
> the answer to that question really drives everything else.

i have a setup a sftp-only ssh for those ldap/ad users,
each one limited (ssh chrootdirectory) to their homedirectory

https://wiki.debian.org/LDAP/NSS
(sssd caching though)

>
> > I came accross this old info:
> > https://github.com/tillsteinbach/gitolite-ldap-config
>
> That looks like the intent is for people to use password
> authentication
> over ssh, and I presume that password is verified using the
> aforementioned LDAP server.

yes, password verification via a remote ldap/ad server

> My personal concern with that issue is
> if you're using git submodules the git URL is embedded inside of the
> repository and people using the "username@gitserver" style URLs would
> break with that. If you don't use submodules this is not a concern.

submodules are not likely to be used in this case
(at least not private ones)

>
> I will note that the security on the above setup depends on a script
> (the "gitolite-shell-force-noninteractive.sh" script) that looks
> trivial to defeat.

do you have other suggestions?

>
> Sadly, given the modern Internet I doubt having a "stable" setup for
> years, much less decades, is feasible. The constant battle of
> security marches on.
>

:) , maintenance is one thing, always having to start from scratch is
another

tnx for the feedback,
Wim


Ken Hornstein

unread,
Sep 19, 2024, 11:14:17 AM9/19/24
to Wim Bertels, gito...@googlegroups.com
>i have a setup a sftp-only ssh for those ldap/ad users,
>each one limited (ssh chrootdirectory) to their homedirectory
>
>https://wiki.debian.org/LDAP/NSS
>(sssd caching though)

The meta-issues here are complicated, and with anything involving security
there are tons of trade-offs.

My personal concern here is this setup requires you to put all of
your users in the password database which exposes those users to all other
programs on that system. This kind of defeats the whole purpose of
gitolite in my mind, as gitolite is constructed so you DON'T have to do
that. In addition, because you authenticate to the ssh server as
individual users you have to perform a bunch of gyrations, usually
involving "sudo", to switch your userid to the gitolite user and that's
a lot of moving parts and crossing of authentication boundaries (you
authenticate as user "foo", THEN become root, THEN become the gitolite
user).

Now it must be said that plenty of people regard this as perfectly
acceptable, and I can understand why they feel that way. I've certainly
done plenty of weird security-related gyrations in my day. I just
feel you need to go into that with your eyes completely open as to
how this works and understand all of the implications.

>> I will note that the security on the above setup depends on a script
>> (the "gitolite-shell-force-noninteractive.sh" script) that looks
>> trivial to defeat.
>
>do you have other suggestions?

Well, the SPECIFIC concern that the above script is addressing is that
if a user gets onto that system without going through the ssh system
they could access any gitolite repo given the sudo configuration. That
script works by running the "tty" command, but that is easy to bypass.
I'm not sure there's a wonderful solution there, given that this setup
requires you to put all of your users in the password database. Yes,
you can carefully lock down ssh, but that really is putting all of your
eggs in one basket.

In terms of a larger issue, since you are using AD Kerberos authentication
is an option; I posted my configuration for that on this list a month
ago. I will be the first to admit that even though I think Kerberos is
good authentication protocol, it can be complicated to implement; again,
one of those security trade-offs.

--Ken

German Salazar

unread,
Sep 19, 2024, 3:59:18 PM9/19/24
to Ken Hornstein, Wim Bertels, gito...@googlegroups.com
If memory serves me correctly, I believe gitolite was the precursor of gitlab.  
I myself started with gitolite; I have now migrated to Gitlab Community Edition. 


--
You received this message because you are subscribed to the Google Groups "gitolite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gitolite+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gitolite/20240919151414.3ED2A20F9B%40pb-smtp1.pobox.com.
Reply all
Reply to author
Forward
0 new messages