gitolite/doc/users.mkd
Sitaram Chamarty bbaacfaee7 (mostly) doc changes
- minor typo fixes, clarifications, etc.

  - keep sts.html url consistent, because many people link to
    http://sitaramc.github.com/gitolite/sts.html

  - create a common migration doc, so the old 'migr.html' does not 404
    when g3 docs become "main"

  - progit doc done

  - add gitosis convert script (FWIW)

  - a minor comment fix to Sugar.pm
2012-04-10 15:41:32 +05:30

68 lines
2.5 KiB
Markdown

# adding and removing users
Strictly speaking, gitolite doesn't know where users come from. If that
surprises you, read [this][auth]. However, gitolite does help with ssh-based
authentication, so here's some info on adding and removing users.
> ----
> *WARNING: Do NOT add users directly on the server. Clone the
> 'gitolite-admin' repo to your workstation, make changes to it, then add,
> commit, and push. When the push hits the server, the server "acts" upon
> your changes.*
> ----
All operations are in a clone of the gitolite-admin repo.
To **add** a user, say Alice, obtain her public key (typically
`$HOME/.ssh/id_rsa.pub` on her workstation), copy it to `keydir` with the user
name as the basename (e.g., 'alice.pub' for user alice), then `git add
keydir/alice.pub`. (All keys files must have names ending in ".pub", and must
be in openssh's default format).
To **remove** a user, `git rm keydir/alice.pub`.
In both cases, you must commit and push. On receiving the push, gitolite will
carry out the changes specified.
The user name is simply the base name of the public key file name. So
'alice.pub', 'foo/alice.pub' and 'bar/alice.pub', all resolve to user "alice".
## #multi-key multiple keys per user
The simplest and most understandable is to put their keys in different
subdirectories, (alice.pub, home/alice.pub, laptop/alice.pub, etc).
### old style multi-keys
There is another way that involves creating key files like `alice@home.pub`
and `alice@laptop.pub`, but there is a complication because gitolite also
allows *full email addresses* as user names. (I.e., `sitaramc@gmail.com.pub`
denotes the user called `sitaramc@gmail.com`).
This older method of enabling multi-keys was developed to deal with that. It
will continue to work and be supported in *code*, simply because I prefer it.
But I will not accept questions or doc patches for it, because it seems it is
too difficult to understand for a lot of people. This table of sample pubkey
filenames and the corresponding derived usernames is all you get:
* plain username, no multikey
sitaramc.pub sitaramc
* plain username, with multikeys
sitaramc@laptop.pub sitaramc
sitaramc@desktop.pub sitaramc
* email address as username, no multikey
sitaramc@gmail.com.pub sitaramc@gmail.com
* email address as username, with multikeys
sitaramc@gmail.com@laptop.pub sitaramc@gmail.com
sitaramc@gmail.com@desktop.pub sitaramc@gmail.com