Сведения о центрах сертификации SSH

Сведения о центрах сертификации SSH

Сертификат SSH используется для подписания одного ключа SSH другим ключом SSH. Если вы используете центр сертификации SSH для предоставления членам организации и внешний участник совместной работы с подписанными сертификатами SSH, вы можете добавить ЦС в учетную запись предприятия или организацию, чтобы позволить этим участникам организации использовать свои сертификаты для доступа к ресурсам организации.

После добавления ЦС SSH в вашу организацию или корпоративную учетную запись можно использовать ЦС для подписывания сертификатов SSH клиента для членов организации и внешний участник совместной работы. Эти участники организации могут использовать подписанные сертификаты для доступа к репозиториям этой организации.

Сертификаты, добавленные в корпоративный доступ ко всем организациям, принадлежащим вашей корпоративной учетной записи. Дополнительные сведения см. в разделе Применение политик для параметров безопасности в вашем предприятии.

Вы можете требовать, чтобы участники использовали сертификаты SSH для доступа к ресурсам организации.

При необходимости можно требовать, чтобы участники и внешний участник совместной работы использовали сертификаты SSH для доступа к ресурсам организации. Дополнительные сведения см. в разделе [AUTOTITLE и Управление центрами сертификации SSH в вашей организации](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-security-settings-in-your-enterprise#managing-ssh-certificate-authorities-for-your-enterprise).

Например, вы можете создать внутреннюю систему, которая будет каждое утро выдавать разработчикам новый сертификат. Каждый разработчик может использовать свой ежедневный сертификат для работы с репозиториями вашей организации на GitHub. В конце дня срок действия сертификата может автоматически истекать, благодаря чему ваши репозитории будут защищены от его последующей компрометации.

Участники организации могут использовать подписанные сертификаты для аутентификации даже если вы ввели SAML единый вход (SSO), без необходимости авторизации подписанных сертификатов.

Если вы не сделаете SSH-сертификаты обязательными, члены организации и внешние сотрудники могут продолжать использовать другие способы аутентификации для доступа к ресурсам вашей организации с помощью Git, включая имя пользователя и пароль, personal access tokenа также собственные SSH-ключи.

Участники не могут использовать сертификат для доступа к вилкам репозиториев организации, если только предприятие не позволило ЦС SSH получить доступ к репозиториям пользователей. Дополнительные сведения см. в разделе Сведения о центрах сертификации SSH.

Сведения о URL-адресах SSH с сертификатами SSH

Если для организации требуются сертификаты SSH, чтобы предотвратить ошибки проверки подлинности, члены организации и внешний участник совместной работы должны использовать специальный URL-адрес, содержащий идентификатор организации при выполнении операций Git по протоколу SSH. Это позволит клиенту и серверу упростить согласование используемого для проверки подлинности ключа на компьютере участника. Если участник использует обычный URL-адрес, начинающийся с git@github.com, клиент SSH может предложить неправильный ключ, что приведет к сбою операции.

Этот URL-адрес любой пользователь с доступом на чтение к репозиторию может найти в раскрывающемся меню Код на главной странице репозитория, щелкнув Использовать SSH.

Если у вашей организации нет сертификатов SSH, участники могут продолжать использовать собственные ключи SSH или другие средства проверки подлинности. В таком случае подойдет как специальный URL-адрес, так и обычный URL-адрес, начинающийся с git@github.com.

Выдача сертификатов

При выдаче каждого сертификата необходимо добавить расширение, указывающее, для какого GitHub пользователя этот сертификат. Вы можете указать пользователя по его логину или идентификатору пользователя. Например, вы можете использовать команду ssh-keygen OpenSSH, заменяя KEY-IDENTITY на ваш идентификатор ключа, а USERNAME — GitHub на имя пользователя или идентификатор пользователя. Создаваемый сертификат будет давать право действовать от имени этого пользователя при работе с любыми ресурсами вашей организации. Прежде чем выдавать сертификат, проверьте личность пользователя.

          `login` Чтобы идентифицировать пользователя, используйте`extension:login`:

ssh-keygen -s ./ca-key -V '+1d' -I KEY-IDENTITY -O extension:login@github.com=USERNAME ./user-key.pub

Чтобы использовать user ID, используйте extension:id:

ssh-keygen -s ./ca-key -V '+1d' -I KEY-IDENTITY -O extension:id@github.com=ID ./user-key.pub

Для CA, загруженных после 27 марта 2024, необходимо использовать -V флаг для настройки срока службы менее 366 дней для сертификата. Для CA, загруженных до этой даты, этот -V флаг необязательный, и вы можете создавать сертификаты, которые будут безотзывными и живут вечно.

Если у вас есть устаревшие CA, освобождённые от требования истечения срока действия, вы можете обновить CA для обеспечения соблюдения этого требования. Дополнительные сведения см. в разделе [AUTOTITLE и Управление центрами сертификации SSH в вашей организации](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-security-settings-in-your-enterprise#managing-ssh-certificate-authorities-for-your-enterprise).

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

Чтобы выдать сертификат для пользователя, использующего SSH для доступа к нескольким GitHub продуктам, можно добавить два расширения для входа, чтобы указать имя пользователя для каждого продукта. Например, следующая команда выдаёт сертификат для USERNAME-1 для учетной записи пользователя для GitHub Enterprise Cloud, и USERNAME-2 для учетной записи пользователя на GitHub Enterprise Server или GitHub Enterprise Cloud с размещением данных в HOSTNAME.

ssh-keygen -s ./ca-key -V '+1d' -I KEY-IDENTITY -O extension:login@github.com=USERNAME-1 extension:login@HOSTNAME=USERNAME-2 ./user-key.pub

С помощью расширения source-address вы можете ограничить список IP-адресов, с которых участник организации может получать доступ к ее ресурсам. Это расширение принимает отдельные IP-адреса или диапазоны IP-адресов в нотации CIDR. Вы можете указать несколько адресов или диапазонов, разделяя значения запятыми. Дополнительные сведения см. в разделе "Бессерверная маршрутизация между доменами" в Википедии.

ssh-keygen -s ./ca-key -V '+1d' -I KEY-IDENTITY -O extension:login@github.com=USERNAME -O source-address=COMMA-SEPARATED-LIST-OF-IP-ADDRESSES-OR-RANGES ./user-key.pub