Authentifie Git sans exposer de secret

L’idée reçue

« Un dépôt privé protège les secrets qu’on y committe. »

Un secret committé existe dans l’historique, les clones, les caches et parfois les logs CI. La confidentialité du dépôt ne remplace ni la prévention ni la rotation.

01Choisis un mode d’authentification

Mode

Usage courant

Point de vigilance

HTTPS

poste utilisateur, proxy compatible

utiliser un helper sûr, jamais un token dans l’URL

SSH

poste administré, automatisation contrôlée

protéger la clé privée et vérifier l’hôte

GitHub CLI

authentification et opérations GitHub

contrôler l’hôte, le compte et les scopes

02Inspecte avant de modifier

git remote -v
git config --show-origin --get-regexp \
  'credential|http\..*extraheader|url\..*insteadof' || true

gh auth status
ssh-add -l

Une sortie de diagnostic peut elle-même contenir une information sensible. Masque les identifiants avant de la copier dans un ticket ou une pull request.

03Utilise GitHub CLI sans écrire le token

gh auth login
gh auth status
gh auth setup-git

Le flux interactif évite de mettre le token dans une commande visible dans l’historique du shell. Pour une automatisation, utilise le secret store de la plateforme CI et une variable dédiée, jamais un fichier versionné.

04Configure SSH avec une clé dédiée

ssh-keygen -t ed25519 -C "poste-soria"
ssh-add ~/.ssh/id_ed25519
ssh -T git@github.com

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

La clé privée reste sur le poste. Seule la clé publique est enregistrée côté GitHub. Une passphrase et un agent réduisent le risque d’utilisation directe du fichier volé.

05Interdis les URL avec credential

À proscrire
https://USER:TOKEN@github.com/OWNER/REPOSITORY.git

git remote set-url origin \
  https://github.com/OWNER/REPOSITORY.git

git remote -v

Une URL sensible peut apparaître dans .git/config, une capture d’écran, une trace CI ou une commande archivée.

06Contrôle les fichiers et l’historique

git status --short
git check-ignore -v .env
git ls-files '.env' '*.pem' '*.key'
git log -p --all -- .env
git grep -n -I -E \
  'ghp_|github_pat_|password[[:space:]]*=|token[[:space:]]*='

Ces recherches sont heuristiques : elles réduisent le risque mais ne garantissent pas l’absence de secret.

07Réagis à une exposition

1. Révoquer ou faire expirer le credential.
2. Créer un nouveau credential à privilèges minimaux.
3. Identifier les usages, logs, forks, artefacts et clones concernés.
4. Corriger la source de l’exposition.
5. Décider si une réécriture d’historique est nécessaire.
6. Documenter l’incident sans recopier le secret.

Supprimer le fichier dans un commit suivant ne révoque pas le secret et ne l’efface pas des commits précédents.

08Valide l’hygiène du lab

bash module4-github-collaboration.sh run \
  /tmp/soria-git-github-$USER
bash module4-github-collaboration.sh validate \
  /tmp/soria-git-github-$USER

La validation refuse les motifs de credentials dans les remotes et dans l’arbre final du dépôt simulé.

Défi

Écris une procédure d’accès

Produis une procédure courte pour un nouveau collaborateur : choix HTTPS ou SSH, vérifications, stockage, révocation, changement de poste et informations interdites dans les tickets.

✓À retenir

L’authentification appartient au poste ou à la plateforme d’exécution, jamais au contenu versionné. Un secret suspecté exposé doit être révoqué avant toute opération de nettoyage historique.