为什么我不能在多个 github 存储库上使用一个 ssh 密钥?

对于您链接的 GitHub 页面上的内容，这种描述并不完全正确.事实上，您可以对许多不同的 GitHub 存储库使用相同的 ssh 密钥.你不能做的是对许多存储库使用一个 ssh 密钥和作为他们所谓的部署密钥"，也不能使用相同的 ssh 密钥作为一些其他用户.

That's not quite the right characterization of what it says on the GitHub page you linked. In fact, you can use the same ssh key for many different GitHub repositories. What you can't do is use one ssh key for many repositories and as what they call a "deploy key", nor use the same ssh key as some other user.

这里发生的事情是 GitHub 的 ssh 服务器将传入的密钥分类为以下两种类型之一:

What's going on here is that GitHub's ssh server classifies incoming keys into one of two types:

• 一个帐户密钥，用于将传入连接验证为你.然后，您对一些广泛(或狭窄)的存储库拥有权限，由每个存储库的具有访问权限的帐户"设置控制.也就是说，关键在于他们如何知道您是 kramer65(或您实际使用的任何帐户名称).
• 一个部署密钥，用于验证传入连接是否可以访问一个特定存储库.也就是说，不涉及帐户":它只是一个密钥，附加到一个特定的存储库.

• An account key, which authenticates an incoming connection as you. You then have permissions on some wide (or narrow) swath of repositories, as controlled by each repository's "accounts that have access" settings. That is, the key itself is how they know you are kramer65 (or whatever your account name actually is there).
• A deploy key, which authenticates an incoming connection as having access to one particular repository. That is, there's no "account" involved: it's just one key, attached to one specific repository.

也有机器用户"，但那是一种账户形式；我不确定 GitHub 是否在内部将这些与常规帐户密钥区分开来.因为这些是类似帐户而不是类似部署密钥的，所以您可以让他们访问许多不同的存储库.(这可能就是你想要的.)

There are also "machine users", but those are a form of account; I'm not sure whether GitHub even distinguishes those internally from regular account-keys. Because these are account-like rather than deploy-key-like, you can give them access to many different repositories. (This is probably what you want.)

我真的很想知道；为什么这是个问题?为什么一台服务器不能访问多个存储库?他们正在尝试降低的风险是什么?

I really wonder though; why is this a problem? Why can't one server have access to several repo's? What's the risk they're trying mitigate here?

他们并没有真正保护这里的任何东西.他们只是让您在 GitHub 上保存这个额外的密钥，并且为了(您的)方便，无需创建帐户即可.为了(他们)的方便，他们然后将这一个额外的密钥附加到一个存储库，这让他们的 ssh 服务器——或者实际上，在密钥认证后它背后的东西，即登录外壳"——查找一个允许的存储库不必先通过帐户"表间接.当传入的密钥是帐户(或机器用户)密钥时，他们的 ssh 服务器或它背后的东西必须在这个辅助表中查找，以找到一组允许的存储库.

They are not really protecting anything here. They are just letting you save, on GitHub, this one extra key, and for (your) convenience, do it without bothering to create an account. For (their) convenience, they then attach this one extra key to exactly one repository, which lets their ssh server—or really, what's right behind it after the key authenticates, i.e., the "login shell"—look up the one allowed repository without having to indirect through an "account" table first. When the incoming key is an account (or machine user) key, their ssh server, or what's right behind it, must look in this secondary table, to find the set of allowed repositories.

参见 https://developer.github.com/guides/管理部署密钥/#deploy-keys 了解详情.

(没有理论上的理由他们不能允许部署密钥自动创建一个其他匿名的机器用户"，然后自动添加到每个存储库中，或从其中删除，因为您想要.但是，这对他们没有任何好处，因为机器用户已经存在，并执行相同的功能.他们可以尝试将其作为安全功能旋转，因为它让您知道嘿，那个密钥已经对我来说意味着什么"......但是如果你有那把钥匙并且不应该有那把钥匙，你现在可以找出那把钥匙实际解锁的东西，如果有的话有点反-安全性.另一方面，如果您应该拥有该密钥，而只是忘记了它解锁了您的哪个存储库，则系统对您来说非常困难.这是任何安全系统的典型特征不过:越安全，实际使用就越不方便.)

(There is no theoretical reason they could not allow a deploy key to automatically create an otherwise-anonymous "machine user" that is then automatically added to each repository, or removed from it, as you would like. However, that buys them nothing, since machine users already exist, and perform this same function. They can try to spin it as a security feature because it lets you know "hey, that key already means something to me" ... but if you have that key and aren't supposed to have that key, you can now find out what that one key actually unlocks, which if anything is somewhat anti-security. On the other hand, if you are supposed to have that key, and have simply forgotten which of your repositories it unlocks, that makes the system very difficult for you. This is typical of any security system though: the more secure you make it, the more inconvenient it is to actually use.)