76 lines
3.3 KiB
Markdown
76 lines
3.3 KiB
Markdown
|
# gitolite without ssh
|
||
|
|
|
||
|
|
Gitolite does not actually need ssh. If you managed to read
|
||
|
|
[doc/gitolite-and-ssh.mkd][gas], 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).
|
||
|
|
|
||
|
|
[gas]: http://sitaramc.github.com/gitolite/doc/gitolite-and-ssh.html
|
||
|
|
|
||
|
|
### 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: there are no ssh keys
|
||
|
|
involved if you setup [smart http][sh] mode.
|
||
|
|
|
||
|
|
[sh]: http://sitaramc.github.com/gitolite/doc/http-backend.html
|
||
|
|
|
||
|
|
In other words, authentication is the job of `sshd` or `httpd`, not gitolite.
|
||
|
|
|
||
|
|
### 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][sh] 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][ldap] for more on this.
|
||
|
|
|
||
|
|
[ldap]: http://sitaramc.github.com/gitolite/doc/big-config.html#_storing_usergroup_information_outside_gitolite_like_in_LDAP_
|