Gitolite One User - Many Keys - Different username

Question

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.

Answer 1

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: http://gitolite.com/gitolite/gitolite.html#multi-key

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 "[e-mail]") and then copy the public key to your gitolite keydir directory (gitolite-admin/keydir). When you do that simply name the key [e-mail], [e-mail], and [e-mail]. 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 [e-mail] and [e-mail] 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 [e-mail], [e-mail], and [e-mail] all should have the email address of [e-mail].

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).

Answer 2

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
";

Answer 3

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.

Answer 4

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.

Answer 5

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

Answer 6

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 ;-).