Stockage des credentials Git

Git Credential Manager (GCM) est le helper recommandé : il stocke vos identifiants de façon sécurisée dans le trousseau de clés de l'OS. Mais Git propose aussi des helpers plus simples (cache, store) et vous pouvez opter pour des clés SSH au lieu de tokens HTTPS. Ce guide couvre tous les mécanismes d'authentification Git.

Prérequis : Protocoles Git et Installer et configurer Git.

Ce que vous allez apprendre

• Configurer le helper adapté à votre OS (cache, store, manager)
• Comprendre les différences entre les helpers et leurs niveaux de sécurité
• Gérer les tokens HTTPS et les clés SSH selon la plateforme
• Éviter de retaper vos credentials à chaque opération réseau

Pourquoi un credential helper ?

Sans helper, Git demande le nom d'utilisateur et le mot de passe (ou token) à chaque push, pull et fetch via HTTPS. Un credential helper stocke ces identifiants pour les réutiliser automatiquement.

Les helpers intégrés

cache : en mémoire temporaire

Stocke les identifiants en mémoire pendant 15 minutes (par défaut). Rien n'est écrit sur le disque :

git config --global credential.helper cache

# Augmenter la durée à 1 heure (3600 secondes)
git config --global credential.helper 'cache --timeout=3600'

Idéal pour : sessions de travail courtes, machines partagées.

store : en fichier texte

Enregistre les identifiants en clair dans ~/.git-credentials :

git config --global credential.helper store

Le fichier contient :

https://user:token@github.com

Identifiants en clair

store écrit les tokens en texte brut. Utilisez-le uniquement si vous n'avez pas accès à un gestionnaire de trousseau, et protégez le fichier :

chmod 600 ~/.git-credentials

osxkeychain : trousseau macOS

Intégré avec le Trousseau d'accès macOS (Keychain) :

git config --global credential.helper osxkeychain

Les identifiants sont stockés de façon chiffrée et accessibles via l'app Trousseau d'accès.

Git Credential Manager (GCM)

La solution recommandée. GCM fonctionne sur Linux, macOS et Windows. Il utilise le trousseau de clés natif de l'OS et prend en charge l'authentification OAuth/SAML pour GitHub, GitLab, Azure DevOps et Bitbucket.

Installation

Sur macOS et Windows, l'installation passe par un canal déjà signé : le cask Homebrew et l'installeur de Git for Windows. Sur Linux, la documentation du projet recommande le paquet .deb publié sur la page des releases GitHub, et fournit une procédure de vérification de signature avec debsig-verify. Téléchargez donc le paquet, vérifiez-le, puis installez-le : ne redirigez jamais un script d'installation directement dans un shell.

macOS

brew install --cask git-credential-manager
git-credential-manager configure

Linux (Debian/Ubuntu)

# 1. Télécharger le paquet depuis la release GitHub (adapter la version)
VERSION=2.9.1
curl -fLO "https://github.com/git-ecosystem/git-credential-manager/releases/download/v${VERSION}/gcm-linux-x64-${VERSION}.deb"

# 2. Vérifier la signature GPG du paquet.
#    Import de la clé publique et création de la politique debsig : une seule
#    fois, en suivant la procédure officielle du projet.
#    https://github.com/git-ecosystem/git-credential-manager/blob/main/docs/linux-validate-gpg.md
debsig-verify "gcm-linux-x64-${VERSION}.deb"

# 3. Installer puis enregistrer GCM comme credential helper
sudo dpkg -i "gcm-linux-x64-${VERSION}.deb"
git-credential-manager configure

Windows

GCM est inclus dans Git for Windows et configuré à l'installation. Rien à faire, sauf si vous l'aviez désactivé.

git config --global credential.helper
# manager

Sur Linux, choisissez le magasin de secrets

La documentation de GCM est explicite : « GCM comes without a default store on Linux distributions ». Tant que vous n'avez pas choisi un credential store, GCM refuse de mémoriser quoi que ce soit. Les valeurs disponibles sont secretservice (trousseau du bureau, via l'API freedesktop), gpg (fichiers chiffrés compatibles pass), cache (le cache mémoire de Git) et plaintext (à proscrire).

git config --global credential.credentialStore secretservice

Configuration

git config --global credential.helper manager

# Vérifier
git config --global credential.helper
# manager

GCM ouvre automatiquement le navigateur pour l'authentification OAuth au premier push/pull. Le token obtenu est stocké dans le trousseau de clés de l'OS.

Fonctionnalités de GCM

La ligne qui justifie à elle seule le choix de GCM est OAuth / SAML. Sur une organisation GitHub ou GitLab protégée par du SSO d'entreprise, un simple token personnel est souvent refusé tant qu'il n'a pas été autorisé auprès du fournisseur d'identité ; GCM déclenche le parcours d'authentification complet dans le navigateur et récupère un jeton déjà valide. La ligne Stockage sécurisé indique quel magasin est utilisé selon l'OS, et rappelle que sur Linux ce choix vous revient.

Fonctionnalité	Détail
OAuth / SAML	Authentification via navigateur
Stockage sécurisé	Keychain (macOS), Secret Service (Linux), Credential Manager (Windows)
Multi-comptes	Gestion de plusieurs comptes par plateforme
Proxy	Support des proxies d'entreprise
Plateformes	GitHub, GitLab, Azure DevOps, Bitbucket

Glissez pour voir

SSH keys vs HTTPS tokens

Il n'y a pas de bon et de mauvais choix ici, mais deux modèles de révocation différents. Une clé SSH est un secret durable que vous devez penser à retirer des plateformes le jour où le poste change de mains ; un token HTTPS porte une date d'expiration et un périmètre de permissions, donc il se périme tout seul. Les lignes Pare-feu et Expiration sont celles qui tranchent le plus souvent en entreprise.

Critère	SSH keys	HTTPS + token
Configuration	Génération de clé + ajout sur la plateforme	Token + credential helper
Sécurité	Clé privée chiffrée (passphrase)	Token révocable, scoped
Pare-feu	Port 22 (parfois bloqué)	Port 443 (rarement bloqué)
Multi-comptes	1 clé par compte (SSH config)	1 token par scope
Expiration	Pas d'expiration (sauf rotation manuelle)	Configurable (30/90/365 jours)
CI/CD	Deploy keys	Tokens de service
Facilité	Setup initial plus complexe	Plus simple avec GCM

Glissez pour voir

Recommandation par contexte

Ces quatre situations couvrent la quasi-totalité des cas. Retenez surtout la troisième : sur un runner de CI, une clé SSH personnelle n'a rien à faire, parce qu'elle porte tous vos droits et ne s'expire pas. Un token de service ou une deploy key limitée à un dépôt reste la seule option acceptable.

• Développeur ou équipe : SSH ed25519 (setup unique, très courant en solo comme en équipe, à condition de bien gérer clés et passphrases)
• Équipe avec SSO : HTTPS + GCM (OAuth intégré)
• CI/CD : HTTPS + token de service (scoped, révocable)
• Derrière un pare-feu : HTTPS (port 443), SSH sur port 443 en fallback

Personal Access Tokens (PAT)

Les plateformes Git utilisent des tokens au lieu des mots de passe :

GitHub

GitHub propose deux familles de tokens. Les fine-grained se limitent à des dépôts choisis et à des permissions par ressource, les classic donnent des scopes larges valables sur tout votre compte. Prenez systématiquement un token fine-grained : c'est le seul qui permette de répondre à la question « ce token peut lire quoi, exactement ? ». Le token n'est affiché qu'une fois, à la création.

1. Settings → Developer settings → Personal access tokens → Fine-grained
2. Sélectionnez les permissions (repo, workflow...)
3. Copiez le token, utilisez-le comme mot de passe

GitLab

GitLab distingue les tokens de compte (qui portent vos droits partout), de projet et de groupe. Pour un usage automatisé, préférez un token de projet : il meurt avec le projet et n'ouvre rien d'autre. Le scope read_repository suffit pour un clone ou un pull, write_repository n'est nécessaire que pour pousser.

1. User Settings → Access Tokens
2. Sélectionnez les scopes (read_repository, write_repository...)
3. Copiez le token

Bonnes pratiques tokens

Ces quatre règles se résument à une idée : un token doit avoir une portée et une durée de vie explicites. Le dernier point est le plus violé et le plus coûteux, parce qu'un token committé reste exploitable même après suppression du commit fautif tant qu'il n'a pas été révoqué côté plateforme. Le nettoyage de l'historique est détaillé dans le guide sur les secrets dans Git.

• Scoped : donnez le minimum de permissions
• Expiration : configurez une date d'expiration
• Rotation : renouvelez régulièrement
• Jamais dans le code : utilisez des variables d'environnement ou un credential helper

Gérer plusieurs comptes

Avec SSH (fichier ~/.ssh/config)

L'astuce tient dans le champ Host : github-perso et github-pro sont des alias inventés, ils n'existent pas dans le DNS. C'est HostName github.com qui indique le vrai serveur à contacter. En clonant avec l'alias, vous choisissez implicitement la clé privée employée, sans jamais avoir à passer d'option à git.

# Compte personnel
Host github-perso
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_perso

# Compte pro
Host github-pro
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_pro

git clone git@github-perso:user/repo.git    # Compte perso
git clone git@github-pro:org/repo.git       # Compte pro

Avec HTTPS (conditional includes)

Côté HTTPS, la sélection se fait sur l'emplacement du dépôt sur le disque. La directive includeIf "gitdir:~/work/" charge un fichier de configuration supplémentaire dès que le dépôt courant se trouve sous ~/work/. Vous n'avez donc plus à penser à l'identité utilisée : elle découle du répertoire dans lequel vous avez cloné. La barre oblique finale est obligatoire, elle signifie « ce répertoire et tout ce qu'il contient ».

~/.gitconfig

[includeIf "gitdir:~/perso/"]
    path = ~/.gitconfig-perso

[includeIf "gitdir:~/work/"]
    path = ~/.gitconfig-work

~/.gitconfig-perso

[user]
    email = perso@example.com
[credential "https://github.com"]
    username = user-perso

Dépannage

Un seul symptôme domine largement : Git redemande les identifiants. Avant de changer de helper, vérifiez lequel est réellement actif avec git config --show-origin credential.helper, car une valeur posée au niveau du dépôt l'emporte sur la configuration globale. Les lignes suivantes couvrent les cas où le helper est bien en place mais où l'authentification est refusée pour une autre raison.

Symptôme	Cause probable	Solution
Git redemande le mot de passe	Pas de credential helper	Configurez cache, store ou GCM
remote: Support for password authentication was removed	GitHub n'accepte plus les mots de passe	Utilisez un PAT ou SSH
Token refusé sur un repo	Permissions insuffisantes	Vérifiez les scopes du token
GCM n'ouvre pas le navigateur	Variable DISPLAY manquante (Linux)	export GIT_TERMINAL_PROMPT=1 ou configurez le secret store
Mauvais compte utilisé	Multi-comptes mal configuré	Vérifiez ~/.ssh/config ou includeIf

Glissez pour voir

À retenir

• cache : temporaire (mémoire), pour les sessions courtes
• store : persistant en clair, à éviter si possible
• GCM : recommandé, stockage sécurisé dans le trousseau de l'OS
• SSH keys : setup unique, très courant en solo comme en équipe
• HTTPS + token : plus simple avec GCM, meilleur pour les équipes SSO
• Tokens : toujours scoped, avec expiration, jamais dans le code

Prochaines étapes

Protocoles Git HTTPS, SSH, Git, Local : comprendre les transports.

Installer et configurer Git Configuration initiale, SSH ed25519, .gitconfig.

Secrets dans le code et l'historique Git Évitez de committer des secrets, détectez et nettoyez.

×

📖 Voir la documentation →