4.0 KiB

Raw Blame History

F=password_access password access to gitolite

(a.k.a: turning real users into gitolite users)

problems

This document solves several different problems. But first some names:

alice: our user
server1: a server on which alice has a shell account or the admin is willing to give her one
git@server2: the gitolite host (user@server). Server2 may be, but need not be, the same as server1.

The problems it solves are:

Alice doesn't like ssh keys and wants to stick to password access (which won't work with gitolite!), and she has or can get a real (unix) userid on server1.
Alice is outside your corporate environment and needs to get in to server2 via server1.

It does this by making alice@server1 act like a "proxy" for git@server2.

what the 2 scripts actually do

gl-shell will become the login shell for these users on server1. This shell will forward git clone/fetch/push requests to "git" on server2.

This redirection is so transparent that I had to explicitly code a message ("forwarding to git@server") to make troubleshooting easier.
gl-shell-setup sets things up. It needs to be run on server1, where it changes the user's shell to gl-shell (full path), then sets up an RSA key if needed.

instructions

server setup

Server1:

Add the host key for server2 to /etc/ssh/ssh_known_hosts on server1. And if it ever changes, update it.
```
ssh-keyscan -t rsa,dsa server2 >> /etc/ssh/ssh_known_hosts
```
You will need to copy the 2 scripts supplied (in contrib/real-users) to "/usr/local/bin" on server1 and customise them -- i.e., edit the files and change stuff in the section clearly-marked "site-local changes".

NOTE on fixing the "chsh" function: this is OS-dependent. Use whatever command the OS on server1 requires for this to work. The supplied command is good for Fedora. (Server2's OS does not matter for this customisation, even though the script is needed there also).

Server2: We assume gitolite is already installed on server2.

per-user setup

There are 2 types of users.

Alice uses a password to access server1, or Alice uses a pubkey to access server1 but does not use an agent or enable agent forwarding.
- login as root on server 1.
- make sure a file called 'alice.pub' does NOT exist in the current directory.
- run gl-shell-setup alice. This will create a file called 'alice.pub' (since it does not exist).
alice uses a pubkey to access server1, and does agent forwarding.
- login as root on server 1.
- ask the user for the pubkey she uses or get it from the authorized_keys file in her $HOME/.ssh on server1. Copy it as 'alice.pub' in the current directory.
- run gl-shell-setup alice. (It will not create the pub file, since it already exists).

You can do this for several users in one shot, and collect all the the pubkeys.

Once you have collected all of them, send them to server2 or to someone who has push rights to the admin repo.

some hints, notes and caveats

This doesn't mean all your users have to be like this. You can have normal users also. In fact, you can have users who give you a pub key from their workstation the normal way, as well as use this method. (I strongly suggest that all such keys be placed in keydir/indirect/ instead of in keydir/).

security and trust discussion

For type 1 users, a default key pair (i.e., including a private key) must be generated on server1 and given to the gitolite admin for inclusion as the user's key for gitolite.

This means that the user must implicitly trust server1's administrators, since they can impersonate her to server2. (If server1 and server2 are the same machine or have the same administrators, this does not matter).

For a type 2 user, no keys need to be generated, and this type of user need not trust server1 at all. In fact, she's only using this method due to firewall issues, and the only thing that gl-shell-setup is doing is to run 'chsh'.

4.0 KiB Raw Blame History