Résolution des problèmes d’authentification dans un dépôt

Découvrez comment résoudre les problèmes d’authentification courants lorsque vous clonez, envoyez ou extrayez à partir d’un dépôt dans un codespace.

Dans cet article

Lorsque vous créez un codespace pour un dépôt, vous pouvez généralement utiliser et git pull pour extraire git push et envoyer les modifications apportées à ce dépôt sans aucune authentification supplémentaire. Toutefois, vous pouvez parfois rencontrer des erreurs d’authentification lorsque vous essayez d’exécuter ces opérations.

Vous pouvez également obtenir des erreurs si vous essayez d’interagir avec un dépôt autre que celui à partir duquel vous avez créé le codespace.

Authentification auprès du dépôt à partir duquel vous avez créé le codespace

Si vous essayez d’envoyer ou d’extraire du dépôt à partir duquel vous avez créé le codespace, mais que l’authentification échoue, vous pouvez voir une erreur comme git@github.com: Permission denied (publickey) ou Host key verification failed.

Vous pouvez rencontrer ces erreurs si vous utilisez un dépôt dotfiles avec GitHub Codespaces, et que vous avez configuré Git pour utiliser un protocole autre que HTTPS pour transférer des données vers le dépôt distant. Par exemple, vous avez peut-être configuré Git pour utiliser SSH en incluant des lignes comme celles qui suivent dans un fichier de configuration dans vos dotfiles.

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

GitHub Codespaces utilise le protocole HTTPS par défaut et s’authentifie avec un GITHUB_TOKEN configuré avec un accès en lecture et en écriture au dépôt à partir duquel vous avez créé le codespace. Nous vous recommandons d’utiliser le protocole HTTPS par défaut et GITHUB_TOKEN dans votre codespace. Les autorisations de GITHUB_TOKEN sont généralement limitées à un seul dépôt, conformément au principe de sécurité du privilège minimum. L’authentification SSH n’a pas d’autorisations de dépôt affinées. Par conséquent, une exposition accidentelle de votre clé SSH peut donner à quelqu’un l’accès à tous vos dépôts.

Pour utiliser le protocole HTTPS par défaut, supprimez la configuration en conflit de vos dotfiles. Si votre dépôt dotfiles contient un script d’installation dans un fichier reconnu tel que install.sh, vous pouvez utiliser une logique semblable à la suivante pour exclure la configuration dans les codespaces.

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

Si vous travaillez dans un codespace créé à partir d’un dépôt auquel vous faites confiance et que vous devez utiliser SSH, assurez-vous que votre codespace est configuré pour s’authentifier avec une clé SSH liée à votre compte GitHub. Pour plus d’informations, consultez « Génération d’une nouvelle clé SSH et ajout de celle-ci à ssh-agent ».

Authentification auprès des dépôts à partir lesquels vous n’avez pas créé le codespace

Dans un codespace, le GITHUB_TOKEN est configuré avec un accès en lecture et en écriture au dépôt à partir duquel vous avez créé le codespace. Par défaut, le jeton n’a pas accès à d’autres dépôts. Vous pouvez constater que vous ne pouvez pas cloner un dépôt ou que vous ne pouvez pas envoyer vers un dépôt que vous avez cloné.

Nous vous déconseillons de mettre à jour manuellement la valeur de GITHUB_TOKEN dans un codespace. Si votre projet nécessite un accès à d’autres référentiels, vous pouvez accorder à ces référentiels un accès aux codespaces en répertoriant des autorisations supplémentaires dans la configuration de votre conteneur de développement. Cela permet aux utilisateurs d’accorder les autorisations supplémentaires lorsqu’ils créent un codespace. Toutefois, cela ne modifie pas les autorisations d’un codespace existant. Pour plus d’informations, consultez « Gestion de l’accès à d’autres dépôts dans votre codespace ».

Si vous avez besoin d’accéder à un autre référentiel dans un codespace existant ou si les autorisations dont vous avez besoin sont spécifiques et ne s’appliquent pas à d’autres contributeurs, vous pouvez créer un personal access token avec accès au référentiel et ajouter le jeton à votre codespace. Nous vous recommandons de limiter l’accès au jeton à l’aide d’un fine-grained personal access token, de sélectionner uniquement les dépôts auxquels vous avez besoin d’accéder et de donner l’accès requis à l’autorisation Contenu uniquement. Pour plus d’informations, consultez « Gestion de vos jetons d'accès personnels ».

Vous pouvez ensuite ajouter le jeton comme variable d’environnement dans un codespace ou comme secret pour GitHub Codespaces. Si vous créez un secret, vous devez autoriser uniquement certains référentiels approuvés à y accéder. Quand vous ajoutez un nouveau secret, vous êtes invité à recharger votre codespace existant pour extraire le nouveau secret. Pour plus d’informations, consultez « Gestion des secrets spécifiques à votre compte pour GitHub Codespaces ».

Pour utiliser le jeton pour vous authentifier dans votre codespace, vous disposez des options suivantes.

  • Pendant la création de la variable d’environnement ou le secret, vous pouvez utiliser le nom GH_TOKEN. La variable GH_TOKEN étant utilisée par défaut dans les opérations GitHub CLI, vous pouvez cloner le dépôt à l’aide de la commande gh repo clone OWNER/REPO.

    Toutefois, si vous essayez ensuite d’envoyer vers le dépôt à l’aide de git push, l’assistant d’informations d’identification de Git tente d’utiliser le GITHUB_TOKEN existant pour s’authentifier, et l’authentification échoue. Vous pouvez remplacer l’assistant, mais cela peut entraîner des frictions lorsque vous essayez d’interagir avec le dépôt d’origine à partir duquel vous avez créé le codespace.

  • Vous pouvez cloner le dépôt avec une URL qui inclut le jeton d’accès. Remplacez YOUR-VARIABLE par le nom de la variable d’environnement ou du secret que vous avez créé.

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

    Cela stocke le jeton d’accès pour le dépôt spécifique, de sorte que vous pouvez envoyer et extraire du dépôt sans remplacer l’assistant d’informations d’identification existant.

    Remarque : Si vous clonez de cette façon, le jeton sera visible dans votre configuration Git. Vous ne devez utiliser cette méthode que lorsque vous travaillez dans un codespace créé à partir d’un dépôt auquel vous faites confiance, et vous devez limiter l’étendue du jeton d’accès autant que possible.