38

I have set up gitolite hopefully as per the instructions, and everything is working as planned.

I am slightly unsure as to how the usernames part works, and looking through the docs hasn't helped me - perhaps I'm missing something simple.

If I have two client machines, for use by one real person, but on each of those machines the usernames are, let's say dave and david. How can I organise the keys in keydir and any config file so that they both represent the same user? I get the suffix thing, dave@laptop, dave@desktop (I think), just not how to have different client machine usernames connecting, as it seems to look for this when authenticating (perhaps because of the public key containing user@host information?)

I can give more details if needed - I just didn't want to bombard you all with irrelevant information.

Thanks very much.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
Adam
  • 5,091
  • 5
  • 32
  • 49
  • 6
    If you don't mind, you said my answer was correct but never accepted it. – Steve Ross Jun 11 '12 at 20:25
  • @Steve I think it was someone else who said your answer was correct. What I was actually asking was about having not just different keys, but different usernames too, as gitolite seems to check the connecting username on authentication. – Adam Jun 12 '12 at 16:28
  • why do you need different usernames? You just need to generate a key on each machine with the same username. Not sure why that would be an issue or even why you would want to do that. – Steve Ross Jun 13 '12 at 13:36
  • @Steve I was under the impression that when you generate a key, it takes the username@host from your machine. Gitolite seems to match the username based on the value of this key. Wouldn't changing the username of this key mess things up? – Adam Jun 15 '12 at 09:04
  • 2
    @Adam the username@host you see in the key itself is just the key comment. to my understanding it doesn't take into account the comment generated with the key, the user@host in the comment isn't always user@host an example is keys generated with putty. gitolite generates a username from the filename of the key. – Steve Buzonas Jun 17 '12 at 20:37
  • @Steve when you commit a key to the keydir it adds a line to .ssh/authorized_keys that takes the contents and prefixes it with a forced command being the path to gitolite-shell with a parameter that is the username, the username is generated based on the filename and not the key comment. see http://stackoverflow.com/a/11094223/816584 for the explanation of how the username is generated – Steve Buzonas Jul 09 '12 at 16:08
  • 1
    You should accept the answer acceptable to you. – Prof. Falken Sep 28 '12 at 11:26
  • Having different user names for the same user is a model that doesn't make any sense whatsoever. Especially when it is simple to generate a key and make the key: username@foo.pub username@bar.pub which will support the scenario in a way that makes more logical sense. – Steve Ross Oct 04 '12 at 15:08
  • So to fix your problem of many users (that are technically the same user). Just go into your gitolite repo and rename the keys "john@home.pub, john@work.pub" instead of having john1, john2. Commit and push your changes back to gitolite. Done. – Steve Ross Oct 04 '12 at 15:34
  • 2
    You can now check out the new Gitolite **`ukm`** feature: see [my answer below](http://stackoverflow.com/a/18693539/6309). – VonC Sep 09 '13 at 07:41

8 Answers8

52

The current recommended way according to the documentation

"The simplest and most understandable is to put their keys in different subdirectories [inside your /kedir], (alice.pub, home/alice.pub, laptop/alice.pub, etc)."

reference: https://gitolite.com/gitolite/basic-admin.html#multiple-keys-per-user

The old way

If you are asking how you accomplish the following:

  1. David (home computer)
  2. David (work computer)
  3. David (laptop)

With different ssh keys on each computer you would simply create the key (ie: keygen "david@someemail.com") and then copy the public key to your gitolite keydir directory (gitolite-admin/keydir). When you do that simply name the key david@homecomputer.pub, david@workcomputer.pub, and david@laptop.pub. Add the keys to the repository (git add keydir/.), commit (git commit -m "added David's additional keys") and git push back to the server.

Gitolite is smart enough to know that even though it is a different key the user name (before the @) is still david and will let that user log in and use the ACL for david

Hope this helps

To fix a scenario where you might have john_home.pub john_work.pub open up your gitolite repo (admin repo) and rename the keys in your kedir to john@work.pub and john@home.pub commit and push. Now your user john can login from either machine and use the same username.

Keep in mind, in order for this to work, the email address in the SSH Keys needs to be the same for all of the user's keys. So using the example above, in the keys david@homecomputer.pub, david@workcomputer.pub, and david@laptop.pub all should have the email address of david@foobar.com.

Above was the "old way" do to this and may cause a complication if you have named your keys in the "email address way" contrary to what I stated above gitolite DOES NOT inspect your key for the proper email address. Please ignore (I left the original comment in for clarity).

jelleklaver
  • 162
  • 1
  • 7
Steve Ross
  • 1,228
  • 10
  • 21
  • 1
    This is the correct answer, but I found that the solution to be slightly more complex. I have several differently named accounts that I want to match up to a single user. For example, in the `keydir` folder, I have `steveh@MacBook.local.pub` and `mrh@Macmini.local.pub`. In my `gitolite.conf` file, I have a group defined as `@steveh = steveh@MacBook.local mrh@Macmini.local` and below in the repo permissions section I use my `@sheveh` group name when assigning permissions. For example `RW+ = @steveh`. For information on gitolite groups, see: http://progit.org/book/ch4-8.html – Steve HHH Dec 14 '11 at 00:03
  • 4
    If you are referring to your login on the box then that doesn't matter, you can generate a ssh keypair with the same email address and then you follow the instructions above without having to muck with your gitolite conf like above. – Steve Ross Jan 03 '12 at 21:32
  • Kirill, not sure how you have your environment setup but, it certainly does work for me as I have a setup that works exactly like this. keydir: foo.sauce@imac.pub foo.sauce@ubuntudesktop.pub foo.sauce@windowslaptop.pub – Steve Ross Feb 21 '12 at 23:02
  • 1
    @KirillRoskoliy gitolite rejects keys with an @ sign in them using the gitolite command as the git user, but subsequent users configured through the gitolite-admin repository should work exactly as described – Steve Buzonas Jun 19 '12 at 03:03
  • "Steve" is correct here, not "Steve HHH", if your ssh keys have the same email address in then gitolite is smart enough to figure it out. – Jeremy Nov 07 '12 at 15:39
  • Actually, that doesn't matter, you just need to name the .pub files as I have outlined. Which I stated in my comment above that read: So to fix your problem of many users (that are technically the same user). Just go into your gitolite repo and rename the keys "john@home.pub, john@work.pub" instead of having john1, john2. Commit and push your changes back to gitolite. Done. It is simply bad practice to have the same user with multiple usernames and pretty much would make it virtually impossible to tell who exactly mucked something up (in git logs etc). – Steve Ross Nov 08 '12 at 15:17
11

For Gitolite v3 at least Easiest solution is to use the subfolder system documented here http://sitaramc.github.com/gitolite/users.html

Gitolite will search recursively through the keydir and associate all the .pub as one user. I am using the subfolder system now with a windows laptop and linux dev machine and working fine.

The user@host convention seems way too complicated.

I'm doing something like this:

keydir
 |--mfang
 |    |--laptop01
 |    |      |--mfang.pub
 |    |--linux01
 |    |      |--mfang.pub
 |...etc
fangstar
  • 190
  • 2
  • 10
  • It is hugely helpful to see the plaintext tree diagram! I had to read the top-rated answer twice to absorb the same information that you present so elegantly as a tree. – Ben Johnson Dec 16 '17 at 00:30
4

Since gitolite v3.5.2-10-g437b497 (September 2013, commit 59c817d0), there is an even simpler solution:

ukm, for "user key management".

User key management allows certain users to add and remove keys.

It can introduce a level of delegation, when not just the gitolite admin user can add new ssh public keys, but other users can now do so as well.

It also facilitate adding/removing public ssh keys.

You can see it in action in "contrib/t/ukm.t":

Gitolite documentation includes a section on that topic, but with ukm, it is easier (section "Users that want to manage multiple keys"):

Your gitolite administrator creates your gitolite identity with one of your keys as your initial key. This key can only be managed by the gitolite administrator, not by you. It basically determines under which name you are known to gitolite.

You can add new keys to this identity and remove them at your will.

# The admin can add multiple keys for the same userid.
try "
ADDOK u5 admin u4\@example.org
ADDOK u5 admin u4\@example.org\@home
ADDOK u5 admin laptop/u4\@example.org
ADDOK u5 admin laptop/u4\@example.org\@home
";
jelleklaver
  • 162
  • 1
  • 7
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
3

I've reorganized my gitolite admin keydir a couple times, and still haven't really decided which is the best way to organize things. If you can stick to some conventions, things will certainly be easier, but that isn't always possible. Luckily gitolite is flexible.

In general I prefer not to use a single, flat directory containing all keys, relying solely on the naming convention "user@host.pub" to keep things straight. (This seems to be implied in other answers?) That can become confusing if you have multiple keys on multiple hosts and multiple usernames for a single "real" user (or even the same username for two different users on two different hosts). Using subdirectories helps to organize things -- using a tree of any depth, but typically I just use one level.

The two main options (or even a combination thereof):

  1. one directory per "real" user, with each directory containing multiple keys for that user (e.g., typically one per host).
  2. one directory per (authorized) host, with one (or more) keys per user who will be working on that host. Although the user could copy their private key to another host, that is (in my case) discouraged. In any case, the subdirectories are named after the host where the key was originally generated.

As an example of one subdirectory per user (option #1):

conf
 |--gitolite.conf
keydir
 |--john.doe
 |    |--john@host1.pub
 |    |--john@host2.pub
 |    |--jdoe@host2.pub
 |    |--john.doe@company.com.pub
 |    |--tester@temp-vm43.pub
 |--will.rodgers
 |    |--wrodgers.pub
 |    |--wrodg1234@host2.pub
 |    |--will.rodgers@company.com.pub
 |    |--tester@temp-vm22.pub
 |...etc

Note that:

  • the directory names (under keydir) don't matter to gitolite.
  • the directory name should be universally unique, such as an email address or some other global ID. This allows "git" users with potentially the same username on different hosts.
  • a key like "user.pub" or "user@email.com.pub" might be shared by a user across several hosts; doing this may be discouraged based on policy, however.

In general I prefer and do use option #1, sprinkled with a few examples of option #2. Option #2 could possibly simplify intranet automation if you have servers coming and going (perhaps provisioning & recycling VM's) and want to maintain things at a host level rather than at the user-level, so you can (for example) easily clean up obsolete keys on a decommissioned host (e.g., short-term test VM).

The nice thing about gitolite is that the (re-)organization of the keydir directory does not impact users. But you can easily (inadvertently) lock out your users (or yourself) if not careful.

michael
  • 9,161
  • 2
  • 52
  • 49
  • directory per user is exactly how i wanted to organize, this option doesn't appear to be documented. i only saw the old style that i failed to get to work properly and the directory per host documented – Steve Buzonas Jun 17 '12 at 20:33
  • @steve-buzonas the dir layout is afaik arbitrary; just the key prefix is used as the username (eg, keydir/foo/bar.pub => "foo" is irrelevant and username is "bar".) See ( http://sitaramc.github.com/gitolite/users.html ): "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)." Also ( http://sitaramc.github.com/gitolite/g2/add.html ): "You can also organise them into various subdirectories of keydir if you wish, since the entire tree is searched." I just upgraded; both g2 and g3 do this. – michael Jun 19 '12 at 01:33
  • that was my understanding of it, i'm slightly confused with your example showing a different key prefix for the same user. – Steve Buzonas Jun 19 '12 at 02:58
  • @steve-buzonas that's the original question, no? => "Gitolite: one user, many keys, different usernames"? The key prefix is the set of usernames for the same user; each "real user" gets one directory (arbitrary but unique) dedicated to their keys. You can just have {jdoe@host1.pub, jdoe@host2.pub,...jdoe@hostN.pub}, but nothing prevents John Doe from also being username "john_testuser931@test_vm23.pub", potentially with different permissions than the other "jdoe" usernames (e.g., read-only or limited projects). (If there's one thing that can be said of gitolite, it's extremely flexible.) – michael Jun 20 '12 at 08:04
  • (cont)...it's easy enough to experiment with gitolite users and usernames: the login accounts on server are totally separate from the gitolite users, so there's no sys-admin work required on the server to test this (i.e., no need to create real users on the server.) You just need multiple client accounts to test with (a linux VM would be useful). Just create keys for each user, add them to the keydir directory (anywhere), and push them to the server, and test these users' access to the hosted git repos. Reconfiguring/restructuring takes seconds: move/rename keys, and push again. – michael Jun 20 '12 at 08:14
  • i see, my confusion was i was thinking user in an administrative sense being user means gitolite account. now i see here user is in the sense of the actor in a use case and can have multiple accounts. my initial thought process upon reading assumed you somehow configured all keys within a particular directory to be mapped to a single gitolite account making the directory the username and the pubkey file arbitrary instead of the other way around as it is designed. – Steve Buzonas Jun 21 '12 at 14:19
2

You always connect like this:

git clone gitoliteuser@gitoliteserver:reponame

no matter what user you are. Gitolite identifies you by what public key you are providing. This key is called dave.pub, for example. Anything that is done through an ssh connection with this public key, will be scrutinized by gitolite according where "dave" or "all" is used in the config file.

You are free to set the name and email to be what ever you want on different machines and different repositories. The commits will have that information. But what branch, tree or repositories you can read or write to/from is dictated by how "dave" is restricted in the config file in the admin repo - if you use the same public/private key for ssh.

Hope this helps.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • So how does it match a public key to a user? Is it by the user@host section in authkeys? It seems like it takes the username I'm connecting with (on the client) and looks for a key with that name? – Adam Apr 21 '11 at 12:07
  • It takes whatever is on the left of the .pub file. So you can have dave@wherever.pub and his key can be generated with whatever email address you want. – Steve Ross Feb 21 '12 at 23:21
1

There's a subtle point everyone seems to be missing here, or at least not answering clearly.

The OP asked how to handle the same PERSON using two different USERNAMES and two different (associated) pub-keys on two different PLATFORMS.

Eg. dave@platform_a.pub, and david@platform_b.pub both represent the same real git user.

It'd be easy enough to add both dave & david as users on the "@known" (known users) line in the gitolite.conf file, and put both keys in the keydir, but then there's no way to tell whether that's two separate users, or the same person.

Eg. "git blame" would treat dave and david as two separate users.

Beyond the OP's post, a further complication is what happens if there ARE several Davids working on the same project?

I guess the Davids concerned would have to work out a system (or be content to blame each other ;-).

Dave E
  • 11
  • 1
1

You install gitolite under one user on the server; usually git, and in your SSH connection string, you always explicitly use git@servername to connect to the Git user account. Gitolite will then look at what public key you are offering, find that in your configuration, and treat you as though you are the associated user.

Brian Campbell
  • 322,767
  • 57
  • 360
  • 340
  • This is incorrect, gitolite does indeed seem to look at the connecting user's username. See: http://sitaramc.github.com/gitolite/doc/gitolite-and-ssh.html#_restricting_shell_access_distinguishing_one_user_from_another – Brian Wigginton Apr 29 '11 at 05:27
  • 1
    @Brian When you're using gitolite, you connect as `git@hostname`; the user seen by the SSH protocol is `git`, not your local username. Then, as described in the link you provided, the SSH daemon looks through the authorized keys file, finds the line matching your public key, checks to make sure you're authenticating with the correct private key, and then executes the command listed on that line in the authorized keys file, which calls `gl-auth-command` passing in the associate username for that key; now `gl-auth-command` knows what user is connecting based on the name passed in. – Brian Campbell Apr 29 '11 at 21:07
  • @Brian, I apologize you're absolutely correct. I was misinterpreting an issue I was having which made me think otherwise. +1 – Brian Wigginton Apr 30 '11 at 23:59
  • 1
    While this answer may be factually correct, it does not answer the original question. The OP is asking how to modify the gitolite.conf file to recognise multiple public keys from the same user, rather than how remote connections from multiple users are handled by Gitolite. – Steve HHH Dec 13 '11 at 23:51
0

Gitolite does authentication with ssh forced commands. Every user that has access to a gitolite repository logs in at the use that gitolite is installed under. The hooks take new keys in the keydir and add them to it's authorized keys file configured to use forced commands.

The users are forced to use gitolite shell with a paramater, and that parameter is the username. The following piece of the relevant hook takes the filepath and assigns it to user, it then strips all directories and files with a / in the name. what is left of that will become the username as long as it ends in .pub and it will disregard a single @ sign preceding the .pub suffix as long as there is at least one additional character.

my $user = $f;
$user =~ s(.*/)();                # foo/bar/baz.pub -> baz.pub
$user =~ s/(\@[^.]+)?\.pub$//;    # baz.pub, baz@home.pub -> baz

This provides functionality as such:

keydir
  |--host1
       |--dave.pub
       |--david.pub
  |--host2
       |--dave.pub

The directories are arbitrary, but for organizational purposes the hosts are used to give structure. You end up with two dave users and one david user.

I use a configuration more like this:

keydir
  |--steve
       |--steve@example.com@laptop.pub
       |--steve@example.com@desktop.pub
  |--services
       |--jenkins
            |--jenkins@master-buildhost.pub
            |--jenkins@slave-buildhost.pub
       |--redmine
            |--redmine@dev-server.pub
       |--jira
            |--jira@dev-alias.pub

Again, the directory structure does not matter. This gives me the users steve@example.com, jenkins, redmine, and jira. The steve@example.com user has two keys as well as the jenkins user. If I had more than a single user I would probably have a users subdirectory containing the steve key directory.

Steve Buzonas
  • 5,300
  • 1
  • 33
  • 55
  • i only have a simple understanding of regex, so if someone could please confirm or further explain i can adjust the answer accordingly. – Steve Buzonas Jun 19 '12 at 04:08