1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
|
# Managing users' public keys
Every collaborator's identity on this server is just an SSH public key
file. There's no separate "user account" concept beyond that — adding,
rotating, or revoking access is entirely a matter of editing files in
`gitolite-admin/keydir/` and pushing. Admin-only.
## Where keys live
```
gitolite-admin/keydir/<username>.pub
```
The filename (minus `.pub`) *is* the gitolite username — it's what you
use in `conf/gitolite.conf` group/permission lines, and what shows up as
`hello <username>, this is git@...` when they run `ssh git@... info`.
## Adding a new collaborator
```bash
git clone git@git.veltar.systems:gitolite-admin
cd gitolite-admin
echo 'ssh-ed25519 AAAA... their-comment' > keydir/carol.pub
# then grant access: add carol to a group or a repo stanza in
# conf/gitolite.conf (see the main README for examples)
git add keydir/carol.pub conf/gitolite.conf
git commit -m "Add carol"
git push
```
No server restart needed — pushing to `gitolite-admin` triggers gitolite
to regenerate `/home/git/.ssh/authorized_keys` automatically. Public keys
aren't secret, so they're fine to store as plain files in this repo — the
only thing that actually needs protecting is the *private* half, which
never leaves the collaborator's machine.
**Verify authenticity before adding a key** — confirm out-of-band (a
call, an in-person handoff, a channel you trust) that the key really came
from that person and wasn't swapped for someone else's. Anyone who gets
their key added here can push/pull whatever gitolite grants that
username.
## One person, multiple keys (laptop + phone + etc.)
gitolite allows several key files per username, disambiguated by a
suffix after `@`:
```
keydir/carol@laptop.pub
keydir/carol@phone.pub
```
Both map to the same gitolite user `carol` — either key authenticates as
her, with identical permissions. Useful for adding a second device
without creating a second identity.
## Rotating a key (lost/compromised device, routine rotation)
```bash
cd gitolite-admin
# overwrite with the new key, or use the @suffix scheme above to add the
# new one first and remove the old one once confirmed working
echo 'ssh-ed25519 AAAA...new-key... carol@new-laptop' > keydir/carol.pub
git add keydir/carol.pub
git commit -m "Rotate carol's key"
git push
```
The old private key stops working the moment this push lands — there's
no grace period, no caching to worry about.
## Revoking a collaborator entirely
```bash
cd gitolite-admin
git rm keydir/carol.pub # and keydir/carol@*.pub if she had more than one
# also remove her from any @group lines and repo stanzas in
# conf/gitolite.conf for config cleanliness (not strictly required for
# security — without a key she can't authenticate at all — but avoids
# stale references)
git commit -m "Revoke carol's access"
git push
```
**This does not delete anything she pushed.** Her personal repos (e.g.
`personal/carol/...`, if she had creator rights) and any shared repos she
had access to stay exactly as they are on disk — revoking a key only
blocks future SSH access, it's not a data-deletion operation. If a repo
needs to be handed to someone else or removed, that's a separate,
manual step on gwaihir (see the main README's note on repo deletion).
## Checking who has access to what
Anyone can check their own access:
```bash
ssh git@git.veltar.systems info
```
As admin, you can check anyone's access to a specific repo without them
needing to be present, from a shell on gwaihir itself:
```bash
su - git -c "gitolite access <repo> <username> R any" # or W, or +
```
`DENIED` means no access; anything else means it's granted.
|
