Skip to main content

Устранение неполадок проверки подлинности в репозитории

Узнайте, как устранять распространенные проблемы проверки подлинности при клонировании, отправке или извлечении из репозитория в пространстве кода.

При создании пространства кода для репозитория обычно можно использовать git pull и git push извлекать и отправлять изменения в этот репозиторий без дополнительной проверки подлинности. Однако иногда при попытке выполнить эти операции могут возникать ошибки проверки подлинности.

Если вы пытаетесь взаимодействовать с репозиторием, кроме того, из которого вы создали пространство кода, могут возникнуть ошибки.

Проверка подлинности в репозитории, из который вы создали пространство кода

Если вы пытаетесь отправить или извлечь из репозитория, из которого вы создали пространство кода, но проверка подлинности завершается ошибкой, может git@github.com: Permission denied (publickey) возникнуть ошибка или Host key verification failed.

Эти ошибки могут возникнуть, если вы используете репозиторий dotfiles с GitHub Codespaces, и вы настроили Git использовать протокол, отличный от HTTPS для передачи данных в удаленный репозиторий. Например, возможно, вы настроили Git для использования SSH, включив строки, как показано ниже в файле конфигурации в dotfiles.

[url "git@github.com:"]
  insteadOf = https://github.com/

GitHub Codespaces использует протокол HTTPS по умолчанию и выполняет проверку подлинности с настроенным доступом GITHUB_TOKEN на чтение и запись в репозиторий, из которого вы создали пространство кода. Рекомендуется использовать протокол HTTPS по умолчанию и GITHUB_TOKEN в пространстве кода. Разрешения обычно GITHUB_TOKEN ограничиваются только одним репозиторием, следуя принципу безопасности наименьших привилегий. Проверка подлинности SSH не имеет точных разрешений репозитория, поэтому случайное воздействие ключа SSH может предоставить кому-то доступ ко всем репозиториям.

Чтобы использовать HTTPS по умолчанию, удалите конфликтующую конфигурацию из dotfiles. Если репозиторий dotfiles содержит скрипт установки в распознаваемом файле, например install.sh, можно использовать логику, как показано ниже, чтобы исключить конфигурацию в пространствах кода.

if [ -z "$CODESPACES" ]; then
  git config --global url."git@github.com".insteadOf "https://github.com"
fi

Если вы работаете в пространстве кода, созданном из доверенного репозитория, и необходимо использовать SSH, убедитесь, что пространство кода настроено для проверки подлинности с помощью ключа SSH, связанного с учетной записью GitHub . Дополнительные сведения см. в разделе Создание нового ключа SSH и его добавление в ssh-agent.

Проверка подлинности в репозиториях, из которыми вы не создали пространство кода

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

Не рекомендуется вручную обновлять значение GITHUB_TOKEN пространства кода. Если для проекта требуется доступ к другим репозиториям, вы можете предоставить пространств кода доступ к этим репозиториям, перечислив дополнительные разрешения в конфигурации контейнера разработки. Это позволит пользователям авторизовать дополнительные разрешения при создании пространства кода. Однако он не изменит разрешения существующего пространства кода. Дополнительные сведения см. в разделе Управление доступом к другим репозиториям в кодовом пространстве.

Если вам нужен доступ к другому репозиторию в существующем пространстве кода или если необходимые разрешения относятся к вам и не применяются к другим участникам, можно создать personal access token с доступом к репозиторию и добавить маркер в пространство кода. Мы рекомендуем ограничить доступ маркера с помощью fine-grained personal access token, выбора только репозиториев, к которым требуется доступ, и предоставления необходимого доступа только к разрешениям "Содержимое****". Дополнительные сведения см. в разделе Управление личными маркерами доступа.

Затем маркер можно добавить в качестве переменной среды в пространстве кода или в виде секрета для GitHub Codespaces. При создании секрета следует разрешить доступ только к определенным доверенным репозиториям. При добавлении нового секрета вам будет предложено перезагрузить существующее пространство кода для извлечения нового секрета. Дополнительные сведения см. в разделе Управление секретами конкретной учетной записи для GitHub Codespaces.

Чтобы использовать маркер для проверки подлинности в пространстве кода, у вас есть следующие параметры.

  • При создании переменной среды или секрета можно использовать имя GH_TOKEN. Переменная GH_TOKEN используется по умолчанию в операциях GitHub CLI, поэтому можно клонировать репозиторий с помощью команды gh repo clone OWNER/REPO.

    Однако если вы попытаетесь отправить в репозиторий с помощью git pushпомощника по учетным данным Git, попытается использовать существующий GITHUB_TOKEN для проверки подлинности, и проверка подлинности завершится ошибкой. Вы можете переопределить вспомогательный элемент, но это может привести к трению при попытке взаимодействовать с исходным репозиторием, из которого вы создали пространство кода.

  • Вы можете клонировать репозиторий с URL-адресом, который включает маркер доступа. Замените YOUR-VARIABLE именем созданной переменной среды или секрета.

    git clone https://USERNAME:$YOUR-VARIABLE@github.com/OWNER/REPO`
    

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

    Note

    Если клонировать таким образом, маркер будет отображаться в конфигурации Git. Этот метод следует использовать только при работе в пространстве кода, созданном из доверенного репозитория, и необходимо максимально ограничить область маркера доступа.