Использование одного и того же ключа развертывания для нескольких проектов github

Ответ 1

Единственная причина, проиллюстрированная обходным решением, которое вы ссылаетесь (создание единого "сборщика" или совместное использование одного и того же id_rsa.REPONAME.pub за репо):

избегать обмена общедоступным/закрытым ключом для разных пользователей

Даже если это не так в вашей ситуации (создайте несколько проектов), позволяя повторно использовать один и тот же ключ ssh, откроет возможность для двух разных пользователей использовать один и тот же ключ ssh, который приведет к поражению аутентификации.

Идентификация означает:
"использование определенного ключа ssh должно означать, что вы должны знать, кто его использует".

Страница GitHub Управление ключами развертывания" описывает различные учетные записи с помощью ssh:

• Перенаправление агента SSH. Переадресация агента использует ключи SSH, уже настроенные на вашей локальной машине разработки, когда вы используете SSH на своем сервере и выполняете команды git.
  Вы можете выборочно разрешить удаленным серверам обращаться к локальному ssh-агенту, как если бы он выполнялся на сервере.
  Поэтому нет необходимости копировать свой секретный ключ на сервере.

• Машинные пользователи: (это стратегия "фиктивной учетной записи" ). Присоедините ключ к учетной записи пользователя. Поскольку эта учетная запись не будет использоваться человеком, она называется пользователем машины.
  Вы относитесь к этому пользователю так же, как и к человеку, но приложите ключ к учетной записи пользователя компьютера, как если бы это была обычная учетная запись.
  Предоставьте сотруднику учетной записи или коллективу доступ к репозиториям, к которым он должен получить доступ.
  Таким образом, один закрытый ключ связан с одним "машинным пользователем", по одному на сервер.

• Развернуть ключ (по одному на репо) GitHub), который хранится на сервере и предоставляет доступ к одному репо на GitHub.
  Этот ключ привязан непосредственно к репо, а не к учетной записи пользователя.
  Вместо того, чтобы перейти к настройкам своей учетной записи, перейдите на страницу целевого администратора репо.
  Перейдите к "Deploy Keys" и нажмите "Add deploy key". Вставьте открытый ключ и отправьте его.

На этот раз ключ ssh не привязан к пользователю (для которого вы можете предоставить доступ к нескольким репо), но к одному репо.
Предоставление доступа ssh для нескольких репо было бы эквивалентом "машинного пользователя".

В терминах аутентификации:

• с использованием одного и того же ключа для нескольких репозиций в порядке, когда это делается пользователем (который указал ключ, связанный с его/ее учетной записью)
• использование одного и того же ключа для нескольких репо НЕ выполняется, когда ключ привязан репо, потому что вы вообще не знаете, к кому обращались. Это отличается от "машинного пользователя", когда "пользователь" объявлен как соавтор для многих репо.
  Здесь (Deploy key), нет "соавтора" , только прямой доступ ssh, предоставленный репо.

Ответ 2

Мне потребовалось много времени, чтобы рационализировать последствия и придумал этот сценарий.

Представьте, что вы создаете один ключ развертывания для пользователя, который вы назначили нескольким репозиториям. Теперь вы хотите отменить этот ключ, но он используется в нескольких местах. Поэтому вместо того, чтобы отменить весь доступ, вы можете случайно отменить частичный доступ.

Это может показаться благом, но эта взаимосвязь "один-к-одному" на самом деле по своей сути небезопасна, если вы считаете человеческий фактор. Это связано с тем, что вы не можете точно знать, действительно ли вы отменили весь доступ, не проверяя каждый репозиторий и не сравнивая каждый открытый ключ отдельно в том случае, если вы забыли, где вы его назначили.

Это определенно расстраивает назначение и управление множеством уникальных ключей, но последствия безопасности понятны тем, как GitHub установил свою политику: , когда вы отменяете ключ, вы гарантируете отмену всего доступа, предоставленного этим ключом, потому что он используется только в одном месте.