Introduction

S'authentifier auprès d'un remote Git est principalement invisible jusqu'à ce que cela tourne mal. Les deux mécanismes principaux sont les clés SSH et les identifiants HTTPS (mots de passe ou, plus communément aujourd'hui, jetons d'accès personnels).

Clés SSH

Générez une clé moderne :

ssh-keygen -t ed25519 -C "[email protected]"
ssh-add --apple-use-keychain ~/.ssh/id_ed25519     # macOS
ssh-add ~/.ssh/id_ed25519                           # Linux

Ajoutez la clé publique (~/.ssh/id_ed25519.pub) à votre compte d'hébergement. Testez :

ssh -T [email protected]
# Hi ada! You've successfully authenticated...

Configuration SSH

Les surcharges par hôte vont dans ~/.ssh/config :

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

Identifiants HTTPS

La plupart des hôtes n'acceptent plus les mots de passe de compte ; utilisez un jeton d'accès personnel (PAT) avec les bonnes portées. Git le stocke via un assistant d'identifiants :

git config --global credential.helper cache              # en mémoire, expire
git config --global credential.helper "cache --timeout=86400"
git config --global credential.helper osxkeychain        # macOS
git config --global credential.helper manager            # Windows
git config --global credential.helper store              # fichier en clair (seulement si vous devez)

La première fois que vous poussez, Git vous demande et l'assistant sauvegarde le token.

Inspecter et effacer

echo "url=https://github.com" | git credential fill
echo "url=https://github.com" | git credential reject

git credential est une interface bas niveau vers l'assistant.

Assistants par hôte

git config --global credential.https://github.com.helper manager
git config --global credential.https://gitlab.com.helper cache

Utile quand différents hôtes nécessitent différentes méthodes d'authentification.

Signer commits et tags

Authentification et signature sont différentes. La signature prouve la paternité d'un commit :

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git commit -S -m "Signed commit"
git log --show-signature -1

2FA et SSO

Si votre hôte exige 2FA, l'authentification HTTPS nécessite un PAT (les mots de passe sont bloqués). Pour les organisations protégées par SSO, le PAT doit aussi être autorisé pour le SSO ; sinon les pushes obtiennent une erreur vague « permission denied ».

Identifiants par URL

Le système d'identifiants de Git peut stocker différents identifiants par hôte ou chemin. La clé de correspondance est le préfixe d'URL, vous pouvez donc avoir des tokens séparés pour, par exemple, vos organisations GitHub personnelle et professionnelle :

git config --global credential.https://github.com/work-org.helper manager
git config --global credential.https://github.com/personal.helper "store --file ~/.git-creds-personal"
git credential fill <<<"url=https://github.com/work-org/repo"

Le paramètre credential.useHttpPath dit à Git d'inclure le chemin dans la clé de recherche, permettant des identifiants par dépôt. Utilisez-le seulement quand nécessaire ; il multiplie le nombre d'entrées stockées.

Erreurs fréquentes

Pousser avec un token qui manque les bonnes portées (par ex. read-only) ; le message d'erreur est générique. Accorder des portées trop larges « par sécurité » ; minimisez. Stocker des tokens dans credential.helper store sur des machines partagées ; c'est un fichier en clair. Oublier de téléverser votre clé publique SSH vers l'hôte et être déconcerté par « permission denied (publickey) » ; ssh -vT git@host montre ce qui se passe. Enfin, mélanger les protocoles : assurez-vous que votre URL de remote correspond à votre méthode d'auth ; git remote set-url peut basculer.