3.8 KiB
gitolite without ssh
Gitolite does not actually need ssh. If you managed to read doc/gitolite-and-ssh.mkd, you may have realised that the crux of gitolite is that it be eventually invoked as
/full/path/to/gl-auth-command some-authenticated-gitolite-username
(where the "gitolite username" is a "virtual" username; it does not have to be, and usually isn't, an actual unix username).
sidebar: authentication versus authorisation
Just for completeness, I'd like to loosely define these two animals.
Authentication is the process of verifying that you are who you claim to be. An authentication system will establish that I am the user "sitaram" on my work system. The one behind gmail will similarly establish that I am "sitaramc". And so on...
Authorisation is the process of asking what you want to do and deciding if you're allowed to do it or not.
what does gitolite actually do
With that background, here's the truth about gitolite:
Gitolite does not do authentication. It only does authorisation.
Yes, the default mode of using gitolite does use ssh keys, but all it's doing is helping you setup ssh-based authentication as a convenience to you. But nothing forces you to use it. The best example: gitolite does not setup any keys or passwords if you install it in smart http mode.
In other words, authentication is the job of sshd or httpd, not gitolite.
[SIDE NOTE: This is why an "ssh issue" is almost never a "gitolite issue". It is also why I often ignore emails and IRC messages that seem like just ssh issues if I am too busy. I will never ignore core gitolite issues like that, of course!]
using other authentication systems with gitolite
The bottom line in terms of how to invoke gitolite has been described up at the top, and as long as you manage to do that gitolite won't even know how the authentication was done. Which in turn means you can use whatever authentication scheme you want.
[Side note: it also expects that the environment variable
SSH_ORIGINAL_COMMAND contain the command that the client sent (typically a
git-receive-pack or git-upload-pack command), or in some CGI variables when
using smart http mode.]
However, it has to be an authentication system that is compatible with sshd or
httpd in some form. Why? Because the git client accessing the server only
knows those 2 protocols to "speak git". (Well, the git:// protocol is
unauthenticated, and file:// doesn't really apply to this discussion, so
we're ignoring those).
One common example is LDAP. Let's say you have an LDAP-based authentication
system somewhere. It is possible to make apache use that to authenticate
users, so when a user accesses a git url using
http://sitaram:password@git.example.com/repo, it is LDAP that does the
actual authentication. [I wouldn't know how to do it but I know it is
possible. Patches to this doc explaining how are welcome!]
There are also ssh daemons that use LDAP to store the authorised keys (instead
of putting them all in ~/.ssh/authorized_keys). The clients will still need
to generate keypairs and send them to the admin, but they can be more
centrally stored and perhaps used by other programs or tools simultaneously,
which can be useful.
Finally, gitolite allows you to store group information externally too. See here for more on this.