Votre commande Git échoue dans le terminal d’un Mac distant, alors que vous pensiez utiliser la clé de votre iPad ou de votre ordinateur portable ?

Le dépannage le plus rapide : identifiez d’abord l’appareil qui exécute réellement Git, puis vérifiez les identifiants SSH présents sur cet appareil. Ne copiez pas une clé privée vers un appareil de voyage ou un hôte partagé dont vous ne maîtrisez pas l’effacement.

Cet article s’adresse aux développeurs indépendants qui travaillent depuis un Mac distant pendant un déplacement.
Il concerne aussi les nomades numériques qui passent de l’iPad à un ordinateur léger, ainsi que les consultants qui utilisent parfois un environnement partagé.
Si vous avez besoin d’un accès fiable à un dépôt sans savoir où se trouve la clé utilisée, commencez par le premier jalon ci-dessous.

Jalon de départ : repérer où Git s’exécute

La fenêtre que vous regardez ne suffit pas à déterminer l’origine des identifiants. Un terminal affiché par une session de bureau à distance peut exécuter des commandes sur le Mac distant ; le terminal local de votre iPad ou de votre ordinateur léger, lui, utilise l’environnement de cet appareil. GitHub authentifie la connexion SSH à partir des clés présentées par le client qui établit la connexion, et la clé publique doit être enregistrée dans le compte concerné. La documentation de GitHub sur l’authentification SSH précise ce fonctionnement.

Avant de modifier une configuration, ouvrez un terminal et relevez trois éléments :

  • le nom de l’hôte affiché par hostname ;
  • le compte actif, indiqué par whoami ;
  • l’adresse du dépôt, affichée par git remote -v.

Ces commandes ne prouvent pas à elles seules quelle clé sera utilisée. Elles permettent toutefois d’établir si vous êtes dans le terminal du Mac distant ou dans celui de votre appareil personnel, puis de confirmer que le dépôt utilise bien une adresse SSH plutôt qu’une adresse HTTPS. Faites ce contrôle dans le même terminal que celui où la commande Git échoue.

La distinction entre les identifiants de connexion au Mac et les identifiants GitHub est essentielle. Le mot de passe utilisé pour ouvrir une session distante n’est pas automatiquement une clé GitHub ; inversement, réussir une connexion SSH au Mac ne prouve pas que le dépôt accepte votre identité GitHub. Apple décrit Remote Login comme une fonction d’accès au Mac par SSH ou SFTP, distincte de l’authentification des opérations GitHub. Vérifiez la portée de Remote Login dans la documentation Apple.

Échec d’authentification GitHub SSH sur Mac distant : isoler la panne

Une erreur SSH ne signifie pas nécessairement que votre réseau est en cause. Séparez le diagnostic en trois couches : établir la connexion, faire reconnaître le compte GitHub, puis vérifier les droits sur le dépôt.

La connexion SSH n’aboutit pas

Lancez le test officiel depuis le terminal où vous souhaitez utiliser Git :

ssh -T git@github.com

Si la connexion expire ou si l’hôte est inaccessible, le problème peut se situer avant l’identification du compte : réseau, résolution du nom ou règles appliquées à la connexion SSH. Recommencez depuis le même appareil, puis comparez avec un autre réseau autorisé si vous en avez un. Dans un café ou un espace de travail partagé, un blocage réseau peut expliquer une différence de résultat ; cela ne justifie pas de déplacer votre clé privée vers une machine inconnue.

GitHub documente ce test et les résultats attendus dans ses instructions de vérification d’une connexion SSH. Si l’échec persiste, suivez les étapes de diagnostic SSH de GitHub plutôt que de conclure trop vite à une mauvaise autorisation du dépôt.

Le compte n’est pas reconnu

Si la connexion atteint GitHub mais que le compte n’est pas reconnu, contrôlez la clé publique associée à l’identité utilisée. Une clé privée ne doit pas être collée dans un site ou envoyée à une personne pour diagnostic : c’est la clé publique qui doit être enregistrée dans les paramètres du compte GitHub.

Pour confirmer l’identité présentée, relancez ssh -T git@github.com après avoir vérifié la configuration. Le message de réussite communiqué par GitHub nomme le compte reconnu et précise que GitHub ne fournit pas d’accès shell général. Ce résultat valide l’authentification SSH ; il ne garantit pas, à lui seul, l’accès à chaque dépôt. La procédure officielle d’ajout d’une clé SSH au compte explique comment enregistrer la clé publique.

Le compte est reconnu, mais le dépôt reste inaccessible

Si le test d’identité réussit mais qu’une commande sur le dépôt échoue, vérifiez l’adresse indiquée par git remote -v, le compte reconnu et les autorisations de ce compte sur le dépôt. Un accès SSH valide ne contourne pas les droits d’équipe, les restrictions d’organisation ou les autorisations du projet. Les erreurs de clonage peuvent également venir d’une adresse de dépôt incorrecte ou d’un accès absent ; consultez les indications de GitHub sur les erreurs de clonage et les permissions.

Ne transmettez jamais la sortie complète d’une commande de diagnostic sans la relire : certaines options détaillées peuvent révéler des chemins, des noms de comptes ou des éléments de configuration que vous ne souhaitez pas partager.

Jalon de reprise : vérifier la clé et l’agent sur la bonne machine

Une fois le terminal identifié, recherchez les clés disponibles sur cet appareil avant d’en créer une autre. La liste des noms de fichiers suffit à commencer : ne publiez pas le contenu d’un fichier privé et ne confondez pas un fichier de clé publique, souvent terminé par .pub, avec son fichier privé associé. GitHub recommande de vérifier les clés SSH existantes avant d’en générer de nouvelles.

Si le Mac distant ne possède pas de clé adaptée, décidez d’abord si c’est bien l’endroit approprié pour conserver un identifiant GitHub. Si le Mac vous est attribué et que vous en maîtrisez l’accès, une clé distincte peut limiter la confusion avec les identifiants d’autres appareils. Si vous utilisez un hôte temporaire ou partagé, ne créez pas une clé que vous ne pourrez pas retirer proprement. Les étapes de génération d’une clé et de son ajout à ssh-agent doivent être suivies sur la machine qui lancera effectivement Git.

Ensuite, examinez la configuration SSH de cet utilisateur. Si elle indique un chemin de clé explicite, vérifiez que le fichier existe à cet emplacement et que le compte courant peut y accéder. Une clé présente sur le disque peut ne pas être celle qu’SSH sélectionne : plusieurs identités, une entrée spécifique dans ~/.ssh/config ou un agent vide peuvent changer le résultat.

Pour voir les identités chargées dans l’agent, utilisez :

ssh-add -l

Si la liste ne contient pas la clé attendue, chargez la bonne identité conformément aux instructions officielles, puis relancez le test SSH. Évitez de supprimer des fichiers ou de remplacer une clé existante avant d’avoir identifié les dépôts ou services qui en dépendent. Si vous devez créer une nouvelle clé, ajoutez uniquement sa partie publique au compte GitHub concerné et vérifiez que le nom choisi permet de la reconnaître ultérieurement.

Jalon de continuité : comprendre les demandes répétées de mot de passe

Une demande de saisie après une reconnexion peut concerner la phrase secrète protégeant la clé, et non le mot de passe du compte GitHub ou celui de la session Mac. Repérez précisément le texte de l’invite avant de saisir quoi que ce soit. Une phrase secrète peut protéger une clé privée ; l’agent SSH sert à présenter une identité chargée, mais une session interrompue ou redémarrée peut ne pas conserver son état comme vous l’attendiez.

Sur macOS, la manière d’utiliser ssh-agent et le trousseau dépend de la configuration et de la version du système. GitHub documente l’ajout d’une clé à l’agent et les options macOS associées dans ses instructions de génération et de chargement d’une clé. Vérifiez les réglages sur le Mac où Git s’exécute, puis refaites un essai après une reconnexion réelle.

Ne considérez pas la mémorisation de la phrase secrète comme une suppression de la protection de la clé. Elle modifie la manière dont vous êtes invité à la saisir, pas la nécessité de garder la clé privée sous contrôle. Avant un déplacement, consignez la méthode de reprise dans un gestionnaire de secrets autorisé ou dans votre documentation privée, sans y copier une clé si la politique de votre organisation l’interdit.

Jalon de sécurité : limiter l’exposition et préparer la révocation

L’emplacement de la clé détermine le risque auquel vous l’exposez. Une clé conservée sur votre ordinateur personnel n’a pas le même périmètre qu’une clé déposée sur un ordinateur emprunté, un poste partagé ou un Mac temporaire. Si le Mac distant est accessible par plusieurs personnes, ne supposez pas que le compte GitHub, les fichiers du terminal et l’agent SSH sont automatiquement isolés : vérifiez qui peut accéder à la session et aux fichiers concernés avant d’y laisser un identifiant.

Le transfert d’agent n’est pas une raison pour ignorer ces contrôles. Il peut éviter de copier directement une clé privée sur une autre machine, mais il ne transforme pas un hôte non fiable en environnement sûr ; n’activez ce mécanisme que si vous comprenez le chemin d’accès et si les règles de votre organisation l’autorisent. Si vous ne pouvez pas vérifier l’environnement, choisissez une méthode d’authentification approuvée qui convient à votre compte, ou suspendez l’opération.

Si vous soupçonnez une exposition, retirez du compte GitHub la clé publique correspondante, puis créez et enregistrez un nouvel identifiant dans un environnement que vous contrôlez. GitHub indique comment examiner et supprimer les clés SSH associées à un compte. La révocation est à préparer avant le départ : notez le nom de la clé et le compte concerné, sans stocker la clé privée dans cette note.

Jalon de validation : reprendre le travail sans élargir les droits

Après la correction, testez d’abord l’authentification, puis les opérations nécessaires dans un dépôt auquel vous avez déjà accès. Une lecture réussie ne prouve pas que l’écriture est permise ; n’effectuez donc pas de modification de test sur un dépôt professionnel sans autorisation. Si le projet le permet, utilisez une opération sans impact pour vérifier la lecture, puis confirmez les droits d’écriture avec la procédure convenue par l’équipe.

Avant de revenir à un travail audio, vidéo ou de design qui dépend aussi du code, consignez l’environnement réellement utilisé. Cette note facilite une reprise depuis un autre appareil sans faire circuler la clé privée.

  • [ ] Exécutez hostname et whoami dans le terminal qui lance Git.
  • [ ] Vérifiez avec git remote -v que l’adresse du dépôt correspond au projet attendu.
  • [ ] Confirmez que la clé publique attendue est enregistrée sur le compte GitHub reconnu.
  • [ ] Contrôlez le chemin de la clé et l’état de ssh-agent sur la machine concernée.
  • [ ] Testez l’accès en lecture sur un dépôt autorisé, puis confirmez séparément les droits d’écriture.
  • [ ] Notez où se trouve la clé, qui contrôle cet environnement et comment retirer la clé du compte.
  • [ ] Si l’environnement est temporaire ou partagé, retirez les identifiants selon les règles de l’organisation avant de le quitter.
Symptôme observé Vérification prioritaire Ce que le résultat permet de conclure
La connexion échoue avant l’identification Réseau, résolution de l’hôte et résultat du test SSH Rechercher une panne de connexion avant de modifier les permissions du dépôt
GitHub ne reconnaît pas le compte attendu Clé sélectionnée, clé publique enregistrée et compte associé Corriger l’identité présentée depuis la machine qui exécute Git
L’identité est reconnue, mais le dépôt est refusé Adresse distante et autorisations du compte sur le dépôt Vérifier l’accès au projet plutôt que régénérer automatiquement une clé
Une phrase secrète est redemandée après reconnexion Agent, trousseau et état de la session macOS Distinguer le chargement de la clé de l’authentification GitHub
Environnement où Git s’exécute Emplacement à examiner en premier Décision prudente
Appareil personnel de voyage Répertoire SSH et agent de cet appareil Garder la clé uniquement si l’appareil est sous votre contrôle et si la politique du projet l’autorise
Mac distant qui vous est attribué Clé, configuration SSH et accès au compte de session Utiliser une identité dédiée si vous pouvez en contrôler l’accès et la révocation
Mac temporaire ou partagé Présence de clés, utilisateurs ayant accès et méthode d’effacement Éviter d’y déposer une clé privée ; utiliser une voie approuvée ou suspendre l’opération

Si vous développez aujourd’hui depuis un ordinateur de voyage, vous dépendez du matériel que vous transportez, vous risquez de multiplier les copies d’identifiants en changeant d’appareil, et une panne peut interrompre l’accès au poste local. Un Mac distant peut éviter de déplacer tout l’environnement de développement, mais il ajoute une dépendance au réseau et exige de vérifier sérieusement qui peut accéder à la session et comment les clés sont révoquées. Pour une utilisation durable, la question n’est donc pas seulement « où Git fonctionne ? », mais aussi « qui contrôle les identifiants sur cette machine ? ».

Si vous avez besoin d’un environnement macOS accessible pendant un déplacement, examinez les informations sur les accès Mac de VMSPIN et vérifiez séparément les conditions de location et les options tarifaires. Avant d’y utiliser un compte GitHub, confirmez que la gestion des clés, les accès au système et la procédure de révocation conviennent à votre projet ; si vous ne pouvez pas établir ces limites, ne confiez pas de clé privée à cet environnement.