Authentification⚓︎

Un des avantages de Git est qu'il permet de travailler en local sans avoir besoin d'une connexion internet. Cependant, pour pouvoir travailler en collaboration avec d'autres personnes, il est nécessaire de se connecter à un serveur distant pour pouvoir partager les modifications. Pour cela, il est nécessaire de s'authentifier.

Git peut communiquer avec un serveur distant avec deux protocoles :

protocole HTTPS, qui utilise un couple nom d'utilisateur/mot de passe ou jeton d'authentification
protocole SSH, qui utilise un couple clé privée/clé publique

Nous allons voir comment configurer Git pour utiliser le protocole SSH, qui est plus sécurisé et plus pratique à l'usage.

Préparer ses clefs⚓︎

Vérifier l'existence d'une clé SSH⚓︎

Première étape : vérifier si vous avez déjà une clé SSH. Pour cela, ouvrez un terminal (Git Bash sous windows, n'importe quel terminal sous macos et linux) et tapez :

cd # pour aller dans le répertoire personnel
ls -al .ssh/ # pour lister tous les fichiers du répertoire .ssh

si le répertoire .ssh n'existe pas : vous n'avez pas de clef SSH
si le répertoire .ssh existe, et contient des fichiers id_xxxxxx et id_xxxxxx.pub : vous avez déjà une clef SSH, vous pouvez sauter l'étape de génération de clef.

Création d'une paire de clefs SSH⚓︎

Dans le terminal, utilisez la commande ssh-keygen pour générer une nouvelle paire de clefs SSH :

ssh-keygen

appuyez sur Entrée pour accepter le chemin par défaut
appuyez sur Entrée pour ne pas mettre de mot de passe, ou entrez un mot de passe si vous le souhaitez²

Un couple de clefs SSH est généré dans le répertoire ~/.ssh par défaut. Selon le système et la version de SSH, il peut s'agir de clefs RSA, DSA, ou ED25519 ¹. Vous pouvez refaire un

ls -al .ssh/

pour vérifier la présence des fichiers id_xxxxxx et id_xxxxxx.pub.

Création du couple de clefs : publique `id_ed25519.pub` et privée `id_ed25519`

Transmettre sa clef publique⚓︎

Il faut maintenant donner la clef publique au serveur distant pour pouvoir utiliser notre clef privée pour s'authentifier.

naviguez vers votre vers les "Paramètres utilisateur" dans GitLab : icône utilisateur / préférences / clés SSH
copiez le contenu de la clef publique (fichier id_xxxxx.pub par défaut) - vous pouvez utiliser la commande cat .ssh/id_xxxxx.pub pour afficher le contenu de la clef et la copier.
cliquez sur "Ajouter une nouvelle clé"
collez le contenu dans le champ "Clé" et validez

Les étapes en images

Afficher le contenu de la clef publique : `cat id_xxxxxx.pub`

Coller la clef dans le champ "Clé", vérifier/modifier les autres champs (la date d'expiration)

Configurer son identité locale⚓︎

Lorsqu'on utilise git, les changements (commits) sont attribués à une personne. Pour cela, il est nécessaire de configurer son identité locale. Pour cela, utilisez les commandes suivantes :

git config --global user.name "Votre Nom"
git config --global user.email "votre.addresse@email.tld"

Si vous avez plusieurs identités (par exemple, une pour le travail et une pour les projets personnels), vous pouvez configurer une identité par projet en utilisant la commande git config sans l'option --global.

Dans le cas de la Forge, il est recommandé d'utiliser la même adresse email que celle utilisée pour votre compte (votre adresse académique) pour que les contributions soient bien attribuées à votre compte.

Attention

Toutes ces opérations ne sont à faire qu'une seule fois, pour associer un poste de travail et un serveur. Si vous travaillez avec plusieurs serveurs (ex: forge/gitlab/github..), ou bien avec plusieurs postes de travail, vous devrez répéter tout ou partie de ces opérations :

création d'une paire de clefs sur chaque nouveau poste de travail
association de la clef publique de chaque poste de travail avec chaque serveur

Les clefs ED25519 sont celles recommandées aujourd'hui pour leur sécurité et leur rapidité. ↩
Un mot de passe sur la clef SSH est une sécurité supplémentaire, mais peut être un peu plus contraignant à l'usage. Sans mot de passe, la sécurité de la clef est alors celle du poste de travail. ↩