a103417da2
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.
109 lines
4 KiB
Markdown
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'.
|