On ne présente plus Git, le système distribué de contrôle de version pour gérer les projets de façon efficace, une alternative (par exemple) à SVN se voulant plus souple et plus performante.

Ayant eu à faire la manipulation pour créer un dépôt sur mon serveur domestique et le rendre accessible via SSH avec une paire de clés (publique et privée), je trouve intéressant d’en parler.

Bien que les explications ne manquent pas concernant les étapes de la démarche (Git étant bien documenté en soi), je vous propose une explication détaillée pour achever tout ceci d’un bout à l’autre.

On verra ainsi comment créer un utilisateur “git” sur le serveur, dont le rôle se limitera à exécuter des commandes Git, puis comment créer un premier dépot Git, que l’utilisateur susnommé sera seul à pouvoir manipuler, enfin nous limiterons l’accès à ce compte utilisateur en SSH avec l’utilisation de couples de clés publiques et privées, voilà pourquoi il faudra générer un couple de clés publique/privée.

Création d’un utilisateur “git”.

Cette étape n’est, en elle même, pas spécifique à l’utilisation de git (ni même compliquée en fait), mais elle reste nécessaire et c’est bien de la détailler pour quiconque faisant pour la première fois ce genre de manipulation.

Tout d’abord, on va créer notre utilisateur sur le serveur avec useradd <user>, on se donne les privilèges root (avec su ou en utilisant sudo) puis dans le terminal:
# useradd git


À ce stade là, notre utilisateur git existe sur le système et sans fournir plus d’option que ça à la commande useradd, son dossier par défaut est /home/git, ça tombe bien c’est ce qu’on voulait mais il reste à créer ce dossier, rien de bien compliqué: un mkdir suffit.
# mkdir /home/git


Maintenant il faut que ce dossier appartienne à notre utilisateur git et qu’il ait les droits en lecture et écriture dessus, on va respectivement utiliser chown et chmod:
# chown git:users /home/git
# chmod 755 /home/git


Là on vient de donner la propriété du dossier /home/git à l’utilisateur git et au groupe users qui désigne le groupe par défaut dans lequel un utilisateur se trouve à sa création, à défaut que celui-ci existe faites chown git:git /home/git et le dossier appartiendra au groupe “git” qui s’est créé en même temps que l’utilisateur).

On a également donné les droits en lecture/écriture/exécution à git sur son dossier, les membres du même groupe et les autres n’ont qu’un droit en lecture et exécution.

Là l’utilisateur est bien en place, on va pouvoir s’occuper de la création d’un premier projet Git !

Création d’un projet Git.

Avant toute chose, procurez-vous git pour votre distribution (bah oui !), dans le cas de Debian et ses dérivée (Mint, Ubuntu…) un apt-get install git avec les privilèges root devrait faire l’affaire, utilisant pour ma part Archlinux, un pacman -S git a fait le travail.

On va ensuite décider d’un dossier où placer tous les projets git, on va partir sur l’exemple de /opt/git, qu’il faut donc créer dans opt/.

Pour cela (toujours en root):
# mkdir /opt/git
# chown git:git /opt/git
# chmod 755 /opt/git


En ayant fait l’étape d’avant on comprend ce que ces lignes font: créer un dossier git/ dans opt/ puis on octroie le dossier à l’utilisateur git et à lui uniquement (d’où le fait qu’on donne aussi git en nom de groupe à chmod), puis on définit les droits en lecteur/écriture/exécution pour que l’utilisateur puisse faire ce dont il a besoin dedans.

Il est temps de créer le projet, pour cela:
# su git
$ mkdir /opt/git/projet.git
$ cd /opt/git/projet.git
$ git init --bare


On passe d’abord en utilisateur git avec su (on ne peut d’ailleurs pas le faire autrement puisqu’il n’a pas de mot de passe associé), on créer un dossier destiné à contenir notre premier projet dans /opt/git, on va dedans puis on initialise le projet.

A ce stade le plus gros est fait pour Git, l’idée est maintenant de sécuriser et restreindre l’accès au dépôt qu’à certains utilisateurs auxquels on fait confiance, c’est à dire ceux pour qui le compte git sur le serveur possède la clé publique.

Cette clé servira à déchiffrer ce qu’un utilisateur donné a chiffré avec sa clé privée, SSH se servira des clés de lui-même, pourvu qu’elles soient aux bons endroits et qu’on les ait générées avant, c’est ce que nous allons faire !

 

Générer un couple de clés publique/privée.

C’est assez simple, du coté de votre <>machine client<> (et non pas le serveur), tapez ceci dans un terminal en tant qu’utilisateur (pas en tant que root):
$ ssh-keygen


l’utilisation de la commande ssh-keygen sans fournir d’argument génère deux fichiers dans le dossier .ssh/ de votre répertoire home: id_rsa et id_rsa.pub, le premier contient votre clé privée et le second votre clé publique (d’où le .pub).

Le “rsa” présent dans les noms des fichiers désigne la méthode de chiffrement asymétrique utilisée, par défaut ssh-keygen utilise rsa, mais d’autres sont disponibles, comme ecdsa ou dsa, pour s’en servir il faut utiliser l’option -t de ssh-keygen:
$ ssh-keygen -t ecdsa


Les deux fichiers générés seront alors id_ecdsa et id_ecdsa.pub.

Il est aussi possible de choisir la longueur des clés en nombre de bits grâce à l’option -b, le type de chiffrement conditionne les longueurs possibles utilisables (voir le man de ssh-keygen) pour l’option -b), exemple:
$ ssh-keygen -t ecdsa -b 521


Notez que certaines méthodes de chiffrement sont plus robustes que d’autres, notamment ecdsa par rapport à rsa, retenez aussi qu’au plus la clé est longue, au plus le chiffrement sera difficile (et long) à casser, par exemple si vous voulez utiliser rsa, la longueur par défaut est de 2048 bits, il est possible d’augmenter ce nombre (voire de le doubler) toujours avec l’option -b.

Importer sa clé publique sur le serveur.

Bon, à ce stade le compte git sur le serveur est créé, un premier dépôt a été initialisé, et vous avez votre couple clé publique/privé.

Maintenant il va falloir que vous puissiez utiliser git au travers de ssh sur le serveur, pour cela il faut que l’utilisateur git sur le server ait votre clé publique.

Coté client: récupérez le contenu de votre fichier id_ecdsa.pub (ou id_rsa.pub, selon la méthode que vous avez utilisé) par exemple, en le faisant de mon coté:
$ cat ~/.ssh/id_ecdsa.pub
ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBADysewrcaOUZl2wHNssiCwO2a6msDZ4FIOgjv9Hh5M1GQKcHQ3SiqJJWdOklnZ8Y7Jp65gF7gR/RL1qfvaQWSgZZgA58VBgZk9g8PMyok13Pn2i6ye9gQR94R1n/h7HyDHZXkpj91RskPE52u2qSZv3SDTZLOOeC4V/xCpj/f9ONf3usQ== blax@blax-arch


Là vous pouvez voir le contenu de mon fichier id_ecdsa.pub, la clé publique est (comme son nom le suggère) faite pour être connue des autres, à l’opposé de la clé privée que vous ne devez jamais divulguer.

On voit une longue ligne avec en premier le type de chiffrement utilisé, suivi de la clé en question (sa longueur dépend de ce que vous avez choisi de faire avec ssh-keygen), puis à la fin un commentaire (qui n’aura aucune incidence sur ce que SSH fera) qui indique mon nom d’utilisateur et le nom de ma machine, c’est complètement facultatif mais il est de mauvais aloi de le supprimer: c’est ce commentaire qui vous permettra par la suite de distinguer les clés les unes des autres (dans l’optique où vous en ajouteriez plusieurs).

il suffit ensuite simplement de… “copier-coller” ceci dans le fichier authorized_keys du dossier .ssh/ de l’utilisateur git sur le serveur.
Normalement ce fichier en question n’existe par encore, ni le dossier .ssh/, pas de problème, on peut les créer, comme les fois d’avant loguez vous sur le serveur avec votre compte utilisateur, passez en root puis faites:
# su git
$ mkdir ~/.ssh
$ touch ~/.ssh/authorized_keys
$ vi ~/.ssh/authorized_keys


le fichier a été créé, puis ouvert avec vi (ou vim, ou nano, comme vous voulez), insérer le contenu de votre id_ecdsa.pub à l’intérieur, puis sauvegardez.

Vous pouvez vérifier que ça s’est bien passé:
$ cat /home/git/.ssh/authorized_keys
ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBADysewrcaOUZl2wHNssiCwO2a6msDZ4FIOgjv9Hh5M1GQKcHQ3SiqJJWdOklnZ8Y7Jp65gF7gR/RL1qfvaQWSgZZgA58VBgZk9g8PMyok13Pn2i6ye9gQR94R1n/h7HyDHZXkpj91RskPE52u2qSZv3SDTZLOOeC4V/xCpj/f9ONf3usQ== blax@blax-arch


Le contenu du fichier devrait être le même sur celui de votre <em>id_ecdsa.pub</em> coté machine client.

Normalement à ce stade là tout devrait être bon MAIS (car il y a un mais) selon la configuration de sshd sur votre serveur, il se peut que votre utilisateur git n’ait pas le droit de se loguer en ssh.

Pour vérifier cela, contrôlez le contenu de /etc/ssh/sshd_config (en étant root sur le serveur), si la ligne AllowUsers est présente, cela veut dire que seuls les utilisateurs indiqués dans la directive ont le droit de se loguer en ssh sur la machine, ajoutez donc git à la liste des utilisateurs, ce qui devrait donner quelque chose du genre:
AllowUsers blax git


Il me semble de bon ton de le préciser, puisque ça n’était pas indiqué dans la procédure que j’ai moi-même suivi pour configurer mon dépôt Git pour la première fois, j’ai donc perdu un certain temps là dessus, mais ça dépend de la configuration par défaut de sshd d’une distribution à l’autre.

Utiliser (enfin) le dépôt Git.

Ça y est, vous pouvez profiter de votre dépôt Git !

Sur votre machine client, avec votre compte utilisateur, essayez de cloner le dépôt:
$ git clone ssh://git@monserveur/opt/git/projet.git


Si tout s’est bien passé, déjà il ne vous sera pas demandé de mot de passe, vous êtes sensé être authentifié à l’aide de votre clé privée (et pourvu que le serveur ait votre clé publique), si un mot de passe vous est demandé, revoyez l’étape concernant la génération de clé (et l’importation sur le serveur).

Au delà de la partie authentification, le dépôt devrait se cloner sans encombre coté client si il a été créé comme il faut coté serveur, sinon revoyez le début du tutoriel.