git 对多个 github 项目使用相同的部署密钥

Using the same deploy key for multiple github projects

提问by David Ebbo

Github does not allow the same ssh deploy key to be used for more than one project, which would be very useful in some cases (e.g. CI server dealing with project with private sub-modules). I've seen various threads that seem to say that this limitation is there for 'security reasons', but I'm yet to see a convincing explanation about exactly what risk that would raise.

Github 不允许将相同的 ssh 部署密钥用于多个项目，这在某些情况下非常有用（例如 CI 服务器处理具有私有子模块的项目）。我已经看到各种线程似乎都在说这个限制是出于“安全原因”而存在的，但我还没有看到关于这会带来什么风险的令人信服的解释。

Note that the fact that Github doesn't allow Account Levelkeys to be reused makes sense (two users shouldn't share keys). It is only the restriction on Deploy Keysthat I'm questioning.

请注意，Github 不允许重复使用帐户级别的密钥这一事实是有道理的（两个用户不应共享密钥）。我所质疑的只是对Deploy Keys的限制。

And to be clear, I'm notlooking for workarounds (create a dummy user, use multiple keys, ...), but only for a plausible explanation for this limitation on Deploy Keys.

需要明确的是，我不是在寻找解决方法（创建一个虚拟用户，使用多个密钥，...），而只是为了对 Deploy Keys 的这种限制进行合理的解释。

Related threads:

相关主题：

• One showing a workaround
• One discussing the issuebut not really going anywhere

• 一个显示解决方法
• 一个在讨论这个问题但没有真正去任何地方

采纳答案by VonC

The only reason, illustrated by the workaround you reference (creating a single "build" user, or sharing the same id_rsa.REPONAME.pubper repo) is:

您引用的解决方法（创建单个“构建”用户或id_rsa.REPONAME.pub每个存储库共享相同的用户）说明的唯一原因是：

avoid sharing public/private key for different user

避免为不同用户共享公钥/私钥

Even though that wouldn't be the case in your situation (build multiple project), allowing to reuse the same ssh key would open the possibility for two differentusers to share the same ssh key, which would defeat the authenticationpurpose.

即使在您的情况下（构建多个项目）情况并非如此，但允许重用相同的 ssh 密钥可能会导致两个不同的用户共享相同的 ssh 密钥，这会破坏身份验证的目的。

Authentication means:
"using a certain ssh key should imply that you are supposed to know whois using it".

身份验证意味着：
“使用某个 ssh 密钥应该意味着您应该知道谁在使用它”。

---

---

The GitHub page "Managing deploy keys" details the various accounts using ssh:

GitHub 页面“管理部署密钥”详细介绍了使用 ssh 的各种帐户：

• SSH agent forwarding: Agent forwarding uses the SSH keys already set up on your local development machine when you SSH in to your server and run git commands.
  You can selectively let remote servers access your local ssh-agent as if it was running on the server.
  So no need to replicate your private key on the server.

• Machine users: (this is the "dummy account" strategy) Attach the key to a user account. Since this account won't be used by a human, it's called a machine user.
  You would treat this user the same way you would a human though, attach the key to the machine user account as if it were a normal account.
  Grant the account collaborator or team access to the repos it needs access to.
  So one private key associated to one "machine user", one per server.

• Deploy key(one per GitHub repo) SSH key that is stored on the server and grants access to a single repo on GitHub.
  This key is attached directly to the repo instead of to a user account.
  Instead of going to your account settings, go to the target repo's admin page.
  Go to "Deploy Keys" and click "Add deploy key". Paste the public key in and submit.

• SSH 代理转发：当您通过 SSH 连接到服务器并运行 git 命令时，代理转发使用已在本地开发机器上设置的 SSH 密钥。
  您可以有选择地让远程服务器访问您的本地 ssh-agent，就像它在服务器上运行一样。
  因此无需在服务器上复制您的私钥。

• 机器用户：（这是“虚拟帐户”策略）将密钥附加到用户帐户。由于此帐户不会被人使用，因此称为机器用户。
  您可以像对待人类一样对待这个用户，将密钥附加到机器用户帐户，就好像它是一个普通帐户一样。
  授予帐户合作者或团队访问其需要访问的存储库的权限。
  因此，一个私钥与一个“机器用户”相关联，每个服务器一个。

• 部署密钥（每个 GitHub 存储库一个） SSH 密钥存储在服务器上并授予对 GitHub 上单个存储库的访问权限。
  此密钥直接附加到存储库而不是用户帐户。
  不要转到您的帐户设置，而是转到目标存储库的管理页面。
  转到“ Deploy Keys”并单击“ Add deploy key”。粘贴公钥并提交。

This time, the ssh key isn't attached to a user (for which you could grant access to several repo), but to one repo.
Granting the ssh access for severalrepo would be the equivalent of a "machine user".

这一次，ssh 密钥没有附加到一个用户（您可以授予对多个 repo 的访问权限），而是附加到一个 repo。
授予多个repo的 ssh 访问权限相当于“机器用户”。

In term of authentication:

在认证方面：

• using the same key for several repos is okay when it is done by a user (which has said key associated to his/her account)
• using the same key for several repo is NOT okay when the key is attached by a repo, because you don't know at all whoaccessed what.
  That differs from the "machine user" where a "user" is declared as a collaborator for many repo.
  Here (Deploy key), there is no "collaborator", just a direct ssh access granted to the repo.

• 当用户完成时，对多个存储库使用相同的密钥是可以的（该密钥与他/她的帐户相关联）
• 当密钥由一个存储库附加时，对多个存储库使用相同的密钥是不行的，因为您根本不知道谁访问了什么。
  这与“机器用户”不同，在“机器用户”中，“用户”被声明为许多 repo 的合作者。
  这里 (Deploy key)没有 "collaborator"，只有授予 repo 的直接 ssh 访问权限。

回答by Jens Finkhaeuser

Unfortunately, this is a scenario where github just misinterprets the distinction between a key pair and an account or project.

不幸的是，在这种情况下，github 只是误解了密钥对与帐户或项目之间的区别。

Since a key pair is used for authentication and authorization, it is effectively an identity. Github accounts are another identity. Connecting github accounts to key pairs effecticely establishes a 1:N mapping between github account based identities and key pair identities.

由于密钥对用于身份验证和授权，因此它实际上是一个身份。Github 帐户是另一个身份。将 github 帐户连接到密钥对有效地建立了基于 github 帐户的身份和密钥对身份之间的 1:N 映射。

Conversely, github enforces a 1:N mapping of projects to key pair based identities. The real world analogue is that there is a door granting access to the project that can be unlocked by many different people. But once any of them gets a key to the door, they cannot get any other keys for any other doors, ever again.

相反，github 强制执行项目到基于密钥对的身份的 1:N 映射。现实世界的类比是，有一扇门可以让许多不同的人解锁该项目的访问权限。但是一旦他们中的任何一个拿到了门的钥匙，他们就再也无法获得任何其他门的钥匙了。

It makes sense not to re-use keys often from the perspective of containing breaches if a key gets compromised. But that's just a good administration policy. It doesn't make much sense to prevent a key from being used more than once on principle. That there are some keys for some doors that are never re-used, well, again that's down to policy.

如果密钥被泄露，从包含违规的角度来看，不经常重复使用密钥是有道理的。但这只是一个很好的管理政策。原则上阻止密钥被多次使用并没有多大意义。有些门的一些钥匙永远不会重复使用，嗯，这又取决于政策。

---

---

A slightly more complex view is to illustrate key pairs as roles. You can possess many key pairs, and therefore inhabit many roles. The private key authenticates you for the role.

稍微复杂一点的观点是将密钥对说明为角色。您可以拥有许多密钥对，因此可以扮演许多角色。私钥对您的角色进行身份验证。

Github's deploy key mapping to projects states that a role can never encompass more than one task. That's rarely realistic.

Github 对项目的部署键映射指出，一个角色永远不能包含多个任务。这很少是现实的。

None of which changes what github allows, of course.

当然，这些都不会改变 github 允许的内容。

回答by Zhro

It took me a lot of thinking to rationalize the implications and came up with this scenario.

我花了很多思考来合理化这些含义并想出了这个场景。

Imagine that you create a single deploy key for a user which you've assigned to multiple repositories. Now you want to revoke that key but it's used in multiple places. So instead of being able to revoke all access you may inadvertently only revoke partial access.

想象一下，您为分配给多个存储库的用户创建了一个部署密钥。现在您想撤销该密钥，但它已在多个地方使用。因此，您可能会无意中仅撤销部分访问权限，而不是能够撤销所有访问权限。

This may sound like a benefit but this many-to-one relationship is actually inherently insecure once you consider the human factor. This is because you can't know for sure if you've really revoked all access without inspecting every repository and compare each public key individually in the case that you've forgotten to where you've actually assigned it.

这听起来像是一种好处，但一旦考虑到人为因素，这种多对一的关系实际上是不安全的。这是因为您无法确定是否真的撤销了所有访问权限，而无需检查每个存储库并单独比较每个公钥，以防您忘记将其分配到实际分配的位置。

It's definitely frustrating to assign and manage so many unique keys but the security implications are clear with how GitHub has instituted their policy: when you revoke a key you're guaranteed to be revoking all access granted by that key because it's only used in one place.

分配和管理如此多的唯一密钥确实令人沮丧，但 GitHub 制定策略的方式很明确：当您撤销密钥时，您肯定会撤销该密钥授予的所有访问权限，因为它仅在一个地方使用.