Protocoles Git : HTTP, SSH et Git

Git supporte quatre protocoles de transport : HTTPS, SSH, Git et Local. Dans la pratique, vous choisirez entre HTTPS et SSH. Ce guide explique chaque protocole, ses avantages et ses limites, pour que vous fassiez le bon choix.

Prérequis : Remotes fondamentaux.

Le protocole git:// est déprécié

Le protocole git:// (port 9418) ne doit pas être utilisé : il n'offre ni authentification ni chiffrement et est vulnérable aux attaques man-in-the-middle. GitHub l'a désactivé en 2022. Si vous voyez une URL git://... dans un tutoriel ou projet ancien, remplacez-la par https:// ou git@... (SSH).

Ce que vous allez apprendre

• Comprendre les 4 protocoles Git : local, SSH, HTTP/HTTPS et Git
• Distinguer HTTPS et SSH pour choisir selon votre environnement
• Évaluer les implications de sécurité et de performance de chaque protocole
• Configurer le protocole adapté sur GitHub, GitLab ou un serveur interne

Les quatre protocoles

La colonne URL type est celle qui vous servira le plus souvent, parce qu'elle permet d'identifier le protocole d'un dépôt existant d'un simple coup d'oeil sur la sortie de git remote -v. Notez la forme particulière de SSH, git@github.com:user/repo.git : les deux-points ne séparent pas un port mais l'hôte du chemin. C'est une syntaxe scp héritée, et remplacer ces deux-points par un slash est l'erreur de saisie la plus fréquente. La colonne Port explique à elle seule le choix de la plupart des entreprises : seul le 443 traverse tous les réseaux d'entreprise sans négociation.

Protocole	URL type	Port	Authentification
HTTPS	https://github.com/user/repo.git	443	Token / mot de passe
SSH	git@github.com:user/repo.git	22	Clé SSH
Git	git://github.com/user/repo.git	9418	Aucune
Local	/srv/git/repo.git	Sans objet	Système de fichiers

Glissez pour voir

1. HTTPS (Smart HTTP)

Le protocole le plus courant. Depuis Git 1.6.6, Git utilise le Smart HTTP qui négocie le transfert de manière intelligente (comme SSH).

git clone https://github.com/user/project.git

Authentification

Depuis 2021, GitHub (et d'autres plateformes) n'acceptent plus les mots de passe en HTTPS. Vous devez utiliser un Personal Access Token (PAT) :

# Git demandera vos identifiants : utilisez le PAT comme mot de passe
git push origin main
Username: votre-username
Password: ghp_xxxxxxxxxxxx  # le PAT, pas votre mot de passe

Pour éviter de retaper le token à chaque fois, configurez un credential helper :

# Cache en mémoire (15 min par défaut)
git config --global credential.helper cache

# Cache avec durée personnalisée (1h)
git config --global credential.helper 'cache --timeout=3600'

# Stockage sur disque (attention : en clair)
git config --global credential.helper store

# Git Credential Manager (recommandé sur Windows/macOS)
git config --global credential.helper manager

Avantages et inconvénients

Le seul argument vraiment décisif est le premier de la colonne de gauche : HTTPS passe partout, y compris derrière un proxy d'entreprise qui inspecte le trafic. Les inconvénients tournent tous autour du même point, la gestion du jeton : il expire, il doit être stocké quelque part, et ce stockage est précisément ce que le paragraphe précédent règle. Un jeton compromis donne par ailleurs accès à tous les dépôts couverts par ses droits, alors qu'une clé SSH révoquée n'affecte qu'un poste.

Avantage	Inconvénient
Fonctionne partout (pare-feux, proxies)	Token à gérer
Pas de configuration côté serveur	Moins pratique que SSH pour le quotidien
Authentification par URL possible	Credential helper nécessaire

Glissez pour voir

2. SSH

Le protocole préféré des développeurs pour le quotidien. Une fois la clé configurée, aucune saisie de mot de passe.

git clone git@github.com:user/project.git

Configuration

La procédure ci-dessous se fait une fois par poste de travail, pas une fois par dépôt. Elle produit deux fichiers dans ~/.ssh : une clé privée, qui ne quitte jamais la machine et doit rester en permissions 600, et une clé publique en .pub, celle que vous collez sur la plateforme. Ne confondez jamais les deux au moment du copier-coller : envoyer la clé privée revient à donner l'accès à tous vos dépôts.

1. Générez une clé SSH (si vous n'en avez pas) :

   ssh-keygen -t ed25519 -C "votre@email.com"

   Préférez ed25519 (plus court, plus sûr) à RSA.

2. Ajoutez la clé à l'agent SSH :

   eval "$(ssh-agent -s)"
   ssh-add ~/.ssh/id_ed25519

3. Copiez la clé publique :

   cat ~/.ssh/id_ed25519.pub

4. Ajoutez-la sur GitHub (Settings → SSH and GPG keys) ou GitLab (Preferences → SSH Keys)

5. Testez la connexion :

   ssh -T git@github.com

   Hi username! You've successfully authenticated, but GitHub does not provide shell access.

Avantages et inconvénients

La ligne à retenir est la deuxième de la colonne de droite : le port 22 sortant est fermé sur beaucoup de réseaux d'entreprise et d'hôtels, ce qui rend SSH inutilisable sans le contournement décrit juste après. Le dernier inconvénient est le plus sérieux dans la durée : une clé privée non protégée par phrase de passe, copiée sur un poste partagé ou sauvegardée dans un dépôt, donne un accès permanent que personne ne remarque.

Avantage	Inconvénient
Pas de mot de passe après configuration	Configuration initiale requise
Sûr (chiffrement asymétrique)	Bloqué par certains pare-feux (port 22)
Rapide pour les push/pull quotidiens	Clé privée à protéger

Glissez pour voir

SSH via port HTTPS

Si le port 22 est bloqué, GitHub permet SSH sur le port 443 :

# Dans ~/.ssh/config
Host github.com
  Hostname ssh.github.com
  Port 443
  User git

3. Protocole Git (git://)

Un protocole léger, sans authentification ni chiffrement, écoutant sur le port 9418. Il a été conçu à une époque où la priorité était de distribuer rapidement des dépôts publics, pas de protéger la chaîne d'approvisionnement logicielle. Sa présentation ici a donc une valeur historique : vous le rencontrerez dans d'anciens fichiers .gitmodules ou dans des scripts de build qu'il faut corriger.

git clone git://github.com/user/project.git

Caractéristiques

Ces quatre caractéristiques expliquent à la fois pourquoi ce protocole a existé et pourquoi il a disparu. Sa rapidité venait de l'absence totale de chiffrement et de négociation, gain devenu négligeable avec le matériel actuel. Son absence d'authentification le limitait de toute façon à la lecture seule : aucun git push n'a jamais été possible en git://.

• Le plus rapide pour le transfert (pas de surcharge SSL/SSH)
• Aucune authentification : lecture seule uniquement
• Pas de chiffrement : les données transitent en clair
• Utilisé principalement pour les miroirs de dépôts publics en lecture

Utilisation déconseillée

Le protocole Git n'offre ni authentification ni chiffrement. Il est vulnérable aux attaques man-in-the-middle. Préférez HTTPS ou SSH. GitHub a désactivé ce protocole en 2022.

4. Protocole Local

Git peut travailler directement sur le système de fichiers :

# Chemin absolu
git clone /srv/git/project.git

# Avec le préfixe file://
git clone file:///srv/git/project.git

La différence : sans file://, Git utilise des hardlinks et copies directes (plus rapide). Avec file://, Git utilise le transport réseau (plus lent mais plus propre pour un transfert minimal).

Cas d'usage

Le protocole local sert surtout à deux choses concrètes. La première est l'apprentissage : créer un dépôt nu avec git init --bare dans un dossier voisin permet de s'exercer aux commandes push, fetch et pull sans dépendre d'un compte en ligne. La seconde est la sauvegarde, en clonant vers un disque externe. Attention en revanche au premier cas de la liste : un dépôt Git partagé par NFS entre plusieurs utilisateurs pose des problèmes de verrous et de permissions, mieux vaut alors exposer le dépôt par SSH.

• Dépôts sur un NFS ou partage réseau monté
• Tests locaux : simuler un remote avec un bare repository
• Sauvegardes sur un autre disque

Comparatif

Ce tableau met en regard les quatre protocoles sur les critères qui pèsent réellement dans une décision. Ne vous arrêtez pas à la ligne Performance : l'écart entre HTTPS et SSH est imperceptible sur un dépôt de taille normale, et il ne compense jamais les contraintes des autres lignes. Les deux lignes déterminantes sont Pare-feu, qui décide si le protocole fonctionne chez vous, et Écriture, qui élimine git:// d'emblée pour tout travail collaboratif.

Critère	HTTPS	SSH	Git	Local
Sécurité	TLS	Chiffrement asymétrique	Aucune	Système de fichiers
Authentification	Token/PAT	Clé SSH	Non	Permissions FS
Pare-feu	Passe partout (443)	Parfois bloqué (22)	Souvent bloqué (9418)	N/A
Performance	Bonne	Bonne	Meilleure	Meilleure
Écriture (push)	Oui	Oui	Non (lecture seule)	Oui
Configuration	Faible	Moyenne	Côté serveur	Aucune

Glissez pour voir

Quel protocole choisir ?

La recommandation se joue sur une question simple : qui exécute la commande ? Un humain sur son poste bénéficie de l'agent SSH, qui garde la clé déverrouillée pendant la session, d'où le confort de SSH au quotidien. Un script de CI n'a ni session ni agent : il lui faut un secret injecté par variable d'environnement, ce que le jeton HTTPS fait naturellement. Beaucoup d'équipes utilisent donc les deux protocoles en parallèle sur le même dépôt, et c'est un choix parfaitement cohérent.

Situation	Protocole recommandé
Développeur quotidien	SSH (confort + sécurité)
CI/CD, scripts automatisés	HTTPS avec token (pas d'agent SSH)
Derrière un proxy/pare-feu strict	HTTPS (port 443)
Miroir public en lecture	HTTPS (Git protocol déprécié)
Tests locaux / bare repos	Local

Glissez pour voir

Dépannage : problèmes courants

Ces quatre messages couvrent la quasi-totalité des échecs de connexion à un dépôt distant. Le premier réflexe consiste à identifier le protocole en cause avec git remote -v, car un message d'erreur SSH sur une URL HTTPS signale simplement que vous regardez le mauvais dépôt. Une réserve sur la dernière ligne : http.sslVerify false désactive la vérification du certificat et expose la connexion à une interception. Réservez ce réglage à un diagnostic ponctuel, et ajoutez l'autorité de certification interne au magasin de confiance pour la configuration définitive.

Symptôme	Cause probable	Solution
Permission denied (publickey)	Clé SSH non configurée ou non ajoutée	ssh-add, vérifiez la clé sur la plateforme
fatal: Authentication failed	Token expiré ou mauvais	Régénérez le PAT sur la plateforme
Connection refused (port 22)	Pare-feu bloque SSH	Utilisez HTTPS ou SSH sur le port 443
SSL certificate problem	Certificat auto-signé	git config http.sslVerify false (temporaire) ou ajoutez le CA

Glissez pour voir

À retenir

• HTTPS : fonctionne partout, token requis, idéal pour la CI/CD
• SSH : confort au quotidien, clé à configurer une fois, préférez ed25519
• Le protocole Git (git://) est déprécié, pas d'authentification ni de chiffrement
• Local : pour les tests et les bare repos sur le système de fichiers
• La plupart des développeurs utilisent SSH pour le quotidien et HTTPS pour la CI/CD

Prochaines étapes

Héberger un serveur Git Montez votre propre serveur Git avec SSH ou HTTP.

Plateformes Git GitHub, GitLab, Gitea : comparatif des plateformes.

Credential storage Stockez vos identifiants Git en toute sécurité.

×

📖 Voir la documentation →