gitolite/contrib/real-users/password-access.mkd
Sitaram Chamarty a103417da2 (password access) backward compat breakage for gl-shell-setup; read below
gl-shell-setup has a "run as hosting user" piece that basically
automates the adding of the user's (new) key to the admin repo.

This is now gone.  (It's not that hard to automate yourself if you want
to do it anyway, using gl-admin-push).

I did this because I needed to allow someone in through a gateway, and
realised that that has the exact same needs.  So the whole scheme has
been changed to treat the proxy and the gitolite host as being two
different servers.

At that point it became cumbersome to do the second bit, and I left it
out.

Other changes:
  - you can define exceptions for the default shell in gl-shell
  - the doc has been simplified.
2011-11-15 17:20:17 +05:30

109 lines
4 KiB
Markdown

# 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:
1. 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.
2. 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.
1. 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).
2. 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'.