git Gitolite 一个用户 - 许多键 - 不同的用户名

Gitolite One User - Many Keys - Different usernames

提问by Adam

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

我希望按照说明设置 gitolite，一切都按计划进行。

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

如果我有两台客户端机器，供一个真实的人使用，但在每台机器上的用户名都是，假设是 dave 和 david。如何组织 keydir 和任何配置文件中的密钥，以便它们都代表同一用户？我得到了后缀，dave@laptop，dave@desktop（我认为），只是不知道如何连接不同的客户端机器用户名，因为它似乎在认证时寻找这个（可能是因为包含 user@host 信息的公钥?)

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

如果需要，我可以提供更多细节 - 我只是不想用不相关的信息轰炸你们。

Thanks very much.

非常感谢。

回答by Steve Ross

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

“最简单和最容易理解的方法是将他们的密钥放在不同的子目录中 [在你的 /kedir 内]，（alice.pub、home/alice.pub、laptop/alice.pub 等）。”

reference: http://gitolite.com/gitolite/gitolite.html#multi-key

参考：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)

1. 大卫（家用电脑）
2. 大卫（工作电脑）
3. 大卫（笔记本电脑）

With different ssh keys on each computer you would simply create the key (ie: keygen "[email protected]") and then copy the public key to your gitolite keydir directory (gitolite-admin/keydir). When you do that simply name the key [email protected], [email protected], and [email protected]. Add the keys to the repository (git add keydir/.), commit (git commit -m "added David's additional keys") and git pushback to the server.

在每台计算机上使用不同的 ssh 密钥，您只需创建密钥（即：keygen "[email protected]"），然后将公钥复制到您的 gitolite keydir 目录 (gitolite-admin/keydir)。当你这样做，只是命名键[email protected]，[email protected]和[email protected]。将密钥添加到存储库 ( git add keydir/.)、提交 ( git commit -m "added David's additional keys") 并git push返回到服务器。

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

Gitolite 足够聪明，知道即使它是一个不同的键，用户名（在 之前@）仍然是david并且会让该用户登录并使用 ACLdavid

Hope this helps

希望这可以帮助

To fix a scenario where you might have john_home.pubjohn_work.pubopen up your gitolite repo (admin repo) and rename the keys in your kedirto [email protected]and [email protected]commit and push. Now your user johncan login from either machine and use the same username.

修复您可能已john_home.pubjohn_work.pub打开 gitolite 存储库（管理存储库）并重命名kedirto 中的密钥[email protected]并[email protected]提交和推送的情况。现在您的用户john可以从任何一台机器登录并使用相同的用户名。

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 [email protected], [email protected], and [email protected]all should have the email address of [email protected].

请记住，为了使其工作，SSH 密钥中的电子邮件地址需要与所有用户的密钥相同。因此，使用上面的示例，在键 [email protected]中[email protected]、 和[email protected]都应具有电子邮件地址[email protected]。

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

以上是对此的“旧方法”，如果您以“电子邮件地址方式”命名您的密钥，这可能会导致复杂化，这与我上面所说的相反，gitolite 不会检查您的密钥是否有正确的电子邮件地址。请忽略（为了清楚起见，我保留了原始评论）。

回答by fangstar

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

对于 Gitolite v3，至少最简单的解决方案是使用此处记录的子文件夹系统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.

Gitolite 将通过 keydir 递归搜索并将所有 .pub 关联为一个用户。我现在在 Windows 笔记本电脑和 linux 开发机器上使用子文件夹系统，并且工作正常。

The user@host convention seems way too complicated.

user@host 约定似乎太复杂了。

I'm doing something like this:

我正在做这样的事情：

keydir
 |--mfang
 |    |--laptop01
 |    |      |--mfang.pub
 |    |--linux01
 |    |      |--mfang.pub
 |...etc

回答by VonC

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

自 gitolite v3.5.2-10-g437b497（2013 年 9 月，提交59c817d0）以来，有一个更简单的解决方案：

ukm, for "user key management".

ukm，用于“用户密钥管理”。

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.

它可以引入一定程度的委托，此时不仅 gitolite 管理员用户可以添加新的 ssh 公钥，其他用户现在也可以这样做。

It also facilitate adding/removing public ssh keys.

它还有助于添加/删除公共 ssh 密钥。

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

您可以在“ 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"):

Gitolite 文档包含有关该主题的部分，但使用则更ukm容易（部分“想要管理多个密钥的用户”）：

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.

您的 gitolite 管理员使用您的密钥之一作为初始密钥创建您的 gitolite 身份。此密钥只能由 gitolite 管理员管理，而不能由您管理。它基本上决定了你在 gitolite 下的名字。

您可以向此身份添加新密钥并随意删除它们。

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

回答by michael

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.

我已经重新组织了我的 gitolite 管理 keydir 几次，但仍然没有真正确定哪种是组织事物的最佳方式。如果你能坚持一些约定，事情肯定会更容易，但这并不总是可能的。幸运的是 gitolite 是灵活的。

In general I prefer notto use a single, flat directory containing all keys, relying solelyon the naming convention "[email protected]" 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.

一般来说，我不喜欢使用包含所有键的单个平面目录，仅依赖命名约定“[email protected]”来保持简洁。（这似乎暗示在其他答案中？）如果您在多个主机上有多个密钥并且单个“真实”用户有多个用户名（或者甚至两个不同主机上的两个不同用户使用相同的用户名），这可能会变得混乱。使用子目录有助于组织事物——使用任意深度的树，但通常我只使用一个级别。

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.

1. 每个“真实”用户一个目录，每个目录包含该用户的多个密钥（例如，通常每个主机一个）。
2. 每个（授权）主机一个目录，每个将在该主机上工作的用户有一个（或多个）密钥。尽管用户可以将他们的私钥复制到另一台主机，但（在我的情况下）不鼓励这样做。在任何情况下，子目录都以最初生成密钥的主机命名。

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

作为每个用户一个子目录的示例（选项 #1）：

conf
 |--gitolite.conf
keydir
 |--john.doe
 |    |[email protected]
 |    |[email protected]
 |    |[email protected]
 |    |[email protected]
 |    |[email protected]
 |--will.rodgers
 |    |--wrodgers.pub
 |    |[email protected]
 |    |[email protected]
 |    |[email protected]
 |...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 "[email protected]" might be shared by a user across several hosts; doing this may be discouraged based on policy, however.

• 目录名称（在 keydir 下）与 gitolite 无关。
• 目录名称应该是普遍唯一的，例如电子邮件地址或其他一些全局 ID。这允许“git”用户在不同的主机上可能具有相同的用户名。
• 像“user.pub”或“[email protected]”这样的密钥可能会被一个用户跨多个主机共享；但是，根据政策，可能不鼓励这样做。

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

总的来说，我更喜欢并确实使用选项 #1，并撒上一些选项 #2 的例子。如果您有服务器来来往往（可能是配置和回收 VM）并希望在主机级别而不是在用户级别维护事物，则选项 #2 可能会简化 Intranet 自动化，因此您可以（例如）轻松清理过时的停用主机上的密钥（例如，短期测试 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.

gitolite 的好处是 keydir 目录的（重新）组织不会影响用户。但是，如果不小心，您很容易（无意中）锁定您的用户（或您自己）。

回答by Adam Dymitruk

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.

不管你是什么用户。Gitolite 通过您提供的公钥来识别您。例如，此密钥称为 dave.pub。通过使用此公钥的 ssh 连接完成的任何操作都将由 gitolite 根据配置文件中使用“dave”或“all”的位置进行检查。

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.

您可以在不同的机器和不同的存储库上随意设置名称和电子邮件。提交将包含该信息。但是，您可以读取或写入的分支、树或存储库取决于管理存储库中的配置文件中“dave”的限制方式 - 如果您对 ssh 使用相同的公钥/私钥。

Hope this helps.

希望这可以帮助。

回答by Brian Campbell

You install gitolite under one user on the server; usually git, and in your SSH connection string, you always explicitly use git@servernameto 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.

您在服务器上的一个用户下安装 gitolite；通常git，并且在您的 SSH 连接字符串中，您始终明确使用git@servername来连接到 Git 用户帐户。然后 Gitolite 会查看您提供的公钥，在您的配置中找到它，并将您视为关联用户。

回答by Dave E

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.

OP 询问如何在两个不同的平台上使用两个不同的用户名和两个不同的（关联的）公钥来处理同一个人。

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

例如。dave@platform_a.pub 和 david@platform_b.pub 都代表同一个真实的 git 用户。

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.

将 dave 和 david 添加为 gitolite.conf 文件中“@known”（已知用户）行的用户，并将两个键都放在 keydir 中，这很容易，但是没有办法判断这是否是两个不同的用户，或同一个人。

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

例如。“git blame”会将 dave 和 david 视为两个独立的用户。

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

除了 OP 的帖子之外，如果有几个大卫在同一个项目上工作，会发生什么情况？

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

我猜有关的戴维斯将不得不制定一个系统（或者满足于互相指责;-）。

回答by Steve Buzonas

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.

Gitolite 使用 ssh 强制命令进行身份验证。有权访问 gitolite 存储库的每个用户都以安装 gitolite 的用户登录。钩子在 keydir 中获取新密钥，并将它们添加到配置为使用强制命令的授权密钥文件中。

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 .puband it will disregard a single @sign preceding the .pubsuffix as long as there is at least one additional character.

用户被迫使用带有参数的 gitolite shell，该参数是用户名。以下相关钩子获取文件路径并将其分配给用户，然后删除/名称中带有 a 的所有目录和文件。剩下的将成为用户名，只要它以 结尾，.pub并且只要有至少一个附加字符，它就会忽略后缀@前面的单个符号.pub。

my $user = $f;
$user =~ s(.*/)();                # foo/bar/baz.pub -> baz.pub
$user =~ s/(\@[^.]+)?\.pub$//;    # baz.pub, [email protected] -> 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 daveusers and one daviduser.

目录是任意的，但出于组织目的，主机用于提供结构。您最终有两个dave用户和一个david用户。

I use a configuration more like this:

我使用更像这样的配置：

keydir
  |--steve
       |[email protected]@laptop.pub
       |[email protected]@desktop.pub
  |--services
       |--jenkins
            |[email protected]
            |[email protected]
       |--redmine
            |[email protected]
       |--jira
            |[email protected]

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

同样，目录结构并不重要。这让我的用户[email protected]，jenkins，redmine，和jira。该[email protected]用户有两个键以及与jenkins用户。如果我有多个用户，我可能会有一个包含 steve key 目录的 users 子目录。