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

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

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

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

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

• Один показывает обходной путь
• Один обсуждает проблему, но никуда не денется

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

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

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

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

На странице GitHub « Управление ключами развертывания » подробно описаны различные учетные записи, использующие ssh:

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

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

( DHa указывает в комментариях на число ограничения ключа развертывания и тот факт, что у вас может быть только одна учетная запись пользователя компьютера)

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

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

Что касается аутентификации :

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

К сожалению, это сценарий, в котором github неверно интерпретирует различие между парой ключей и учетной записью или проектом.

Поскольку пара ключей используется для аутентификации и авторизации, это фактически идентификатор. Учетные записи Github - это еще одна личность. Подключение учетных записей github к парам ключей эффективно устанавливает соответствие 1: N между идентификаторами на основе учетной записи github и идентификаторами пары ключей.

И наоборот, github обеспечивает соответствие проектов 1: N идентификаторам на основе пар ключей. Реальный аналог - это дверь, открывающая доступ к проекту, которую могут открыть разные люди. Но как только кто-то из них получает ключ от двери, он больше никогда не сможет получить никаких других ключей от других дверей.

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

Несколько более сложное представление - проиллюстрировать пары ключей как роли . Вы можете обладать множеством пар ключей и, следовательно, исполнять множество ролей. Закрытый ключ аутентифицирует вас для данной роли.

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

Конечно, ничто из этого не меняет того, что позволяет github.

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

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

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

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