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 variableGH_TOKEN
étant utilisée par défaut dans les opérations GitHub CLI, vous pouvez cloner le dépôt à l’aide de la commandegh 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 leGITHUB_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://USERNAME:$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.