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

Github не позволяет использовать один и тот же ключ развертывания ssh для нескольких проектов, что было бы очень полезно в некоторых случаях (например, CI-сервер, работающий с проектом с частными подмодулями). Я видел различные темы, которые, похоже, говорят, что это ограничение существует для "соображений безопасности", но я еще не вижу убедительного объяснения о том, какой риск может повысить.

Обратите внимание, что тот факт, что Github не позволяет использовать ключи уровня аккаунта, имеет смысл (два пользователя не должны делиться ключами). Это только ограничение на Deploy Keys, которое я задаю.

И чтобы быть ясным, я не ищу обходные пути (создаю фиктивный пользователь, использую несколько ключей,...), но только для правдоподобного объяснения этого ограничения для Deploy Keys.

Связанные темы:

Один из способов обхода
Один обсуждает проблему, но не идет никуда.

Ответ 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 установил свою политику: , когда вы отменяете ключ, вы гарантируете отмену всего доступа, предоставленного этим ключом, потому что он используется только в одном месте.