TD08 : Les Clés du DevOps
Authentification SSH - Utilisation de SSH avec GIT
Dernière mise à jour
Authentification SSH - Utilisation de SSH avec GIT
Dernière mise à jour
Comprendre le principe des clés SSH. Les utiliser pour se connecter en SSH sans saisir de mot de passe Les utiliser pour s'authentifier avec GIT et automatiser le déploiement de la sae203
Vous utilisez régulièrement la commande ssh pour vous connecter à votre VPS, ou aux machines de la salle H205 pendant les TPs d'hébergement. Mais ssh ce n'est pas qu'une commande, c'est aussi (et surtout) un protocole qui permet de communiquer entre deux machines de façon sécurisée. Comme vous allez le voir dans ce TD, il permet bien sur de chiffrer (crypter) les données transférées, mais garantit d'abord un niveau d'authentification élevé entre les protagonistes de la session de communication. C'est ce dernier point qui sera développé dans ce TD.
Le protocole SSH (Secure Shell) a été inventé en 1995 par le Finlandais Tatu Ylönen . Si à l'origine il a été écrit pour renforcer la sécurité des sessions à distance, il permet dans sa version 2 (1997) de faire aussi du transfert de fichier (SFTP, SCP) . Comme tout protocole applicatif, il s'appuie sur une protocole de transport (TCP) et possède un numéro de port par défaut : 22. Il est important de ne pas le confondre avec le protocole SSL que nous verrons plus tard, qui lui vient se positionner entre la couche transport et la couche applicative , renforçant ainsi la sécurité sur des protocoles existants comme HTTP ou FTP pour créer les connexions HTTPS et FTPS.
Toute communication sécurisée commence par une phase d'authentification. Que ce soit pour assurer à l'application cliente que le serveur en face de lui est bien le bon, ou pour assurer au serveur que la personne voulant se connecter est bien celle qu'elle prétend être.
Cette phase consiste donc à contrôler de façon fiable l'identité d'une partie en vue d'un échange de données. Cette identité peut être prouvée de plusieurs manières : Soit par un élément que vous seul connaissez (un mot de passe), soit un élément qui vous est propre (une empreinte digitale) ou dans le cas qui nous intéresse par un élément que vous possédez (une clé ).
La cryptographie moderne utilise des algorithmes de chiffrement associés à des clés.
Jusqu'au début des années 70, on utilisait la même clé pour chiffrer et déchiffrer les données, ce qui pose de problèmes en terme de sécurité lors d'une communication
Comment échanger la clé entre l'émetteur et le récepteur des données ?
Comment savoir qui est à l'origine du message si les deux parties utilisent la même clé ?
Il faut autant de clés que d'éléments dans le réseau de communication pour garantir un minimum de confidentialité.
On parle alors de chiffrement symétrique, on ne garantie dans ce cas que la confidentialité des données . Pas d'authentification, ni de garantie de l'intégrité des données.
En 1976, Whitfield Diffie et Martin Hellman publie une méthode d'échange des données asymétrique utilisant deux clés : Une privée, Une publique. C'est ce qu'on nomme aujourd'hui la cryptographie à clé publique. Cette méthode sera reprise par de nombreux algorithmes comme RSA qui est surement le plus connu d'entre eux.
On voit donc dans le schéma ci dessus, que n'importe qui peut chiffrer les données, mais qu'une seule personne (celui qui possède la clé privée) sera capable de déchiffrer le cryptogramme. Tous les algorithmes à clé publique, reposent sur les postulats suivants:
Les deux clés (privée et publique) sont générées conjointement et sont indissociables l'une de l'autre.
On ne peut pas retrouver une clé privée à partir de la clé publique (et vice-versa)
Seule la clé publique doit être distribuée
La clé privée doit être protégée et rester unique (pas de duplication) pour garantir la sécurité de l'ensemble du système de chiffrement.
L'authentification par clé publique fonctionne sur le même principe que le chiffrement, mais en inversant l'utilisation des clés. Le procédé est en effet complétement réversible.
On peut donc chiffrer les données avec la clé privée et les déchiffrer avec la clé publique. Si en terme de confidentialité des données, cela n'a aucun intérêt car tout le monde peut posséder la clé publique, cela permet en revanche de clairement identifier la personne (ou la machine) qui a effectué le chiffrement car elle est la seule à posséder la clé privée.
Dans l'exemple ci-dessus, Alice s'authentifie auprès de Bob grâce à sa clé privée: a) Elle génère une empreinte à partir d'un challenge de son choix (ici : Hello Bob) Pour cela elle utilise un algorithme de hachage (md5 ou sha-256 par exemple) b) Elle chiffre l'empreinte obtenue avec sa clé privée en utilisant un algorithme de chiffrement asymétrique comme rsa ou ecdsa c) Elle envoi le challenge (en clair) et l'empreinte chiffrée à Bob d) Bob recalcule une empreinte à partir du challenge en clair e) Bob déchiffre l'empreinte chiffrée avec la clé publique d'Alice (qu'il doit posséder au préalable) f) Bob compare les deux résultats (empreinte recalculée et empreinte déchiffrée). Si les deux résultats sont identiques, cela confirme que c'est bien Alice qui à établit la communication car elle est la seule à posséder la clé privée qui a chiffré l'empreinte.
Pour conclure cette partie théorique, il suffit donc que vous communiquiez vos clés publiques à vos correspondants pour qu'ils puissent vous authentifier. Voyons maintenant comment cela se concrétise en pratique.
Commençons par quelque chose que vous connaissez déjà, l'authentification de votre VPS lorsque vous réalisez une connexion en SSH.
IMPORTANT : Pour l'instant l'objectif n'est pas de vous authentifier , mais bien d'authentifier le serveur sur lequel vous vous connectez et de lui faire confiance. Dans les exemples qui suivent le CLIENT désigne votre poste de travail, le SERVEUR désigne votre VPS.
Pour bien comprendre ce qu'il se passe, localisez le fichier known_hosts sur votre poste de travail.
Une fois , le fichier localisé, éditez-le avec l'éditeur de texte de votre choix . Vous devriez voir une ou plusieurs clés publiques appartenant aux différents serveurs auxquels vous vous êtes précédemment connectés. En fonction de votre OS, vous devriez aussi voir le nom (ou l'IP des machines) ainsi que le nom des algorithmes de chiffrement utilisés (ici ecdsa).
Pour continuer, supprimez toutes les lignes du fichier . Cela supprimera toutes les clés publiques connues par votre poste de travail. N'ayez pas peur, elles seront réécrites dans le fichier lorsque vous vous reconnecterez aux serveurs.
Une fois les clés supprimées, connectez-vous à votre VPS en utilisant SSH comme d'habitude:
Dans l'exemple ci-dessus, votre poste de travail ne connaissant plus la clé publique de votre serveur, il vous demande de l'authentifier manuellement en confirmant la connexion. Dans notre cas, ce message est bien sur tout à fait légitime car nous avons supprimé les clés connues de notre fichier known_hosts. Si vous ouvrez le fichier, vous devriez d'ailleurs constater que la clé est de nouveau présente.
Voyons maintenant, un autre cas de figure que vous pourriez (ou avez) déjà rencontré
Dans l'exemple ci-dessus, la clé publique du serveur VPS a été modifiée, elle est donc différente de celle enregistrée dans votre fichier known_hosts. Comme vous l'indique le message, s'il est possible que vous soyez victime d'une attaque, il est aussi tout à fait probable que la clé ait été changée suite à une mise à jour du serveur ou à une opération de maintenance de votre VPS. Que fait-il faire ? Sauf si vous pensez vraiment avoir être victime d'une attaque , vous devez juste supprimer la ligne indiquée du fichier known_hosts comme nous l'avons fait précédemment dans ce TD ou saisissez simplement la commande : ssh-keygen -f avec les arguments indiqués dans le message .
Vous pensez être victime d'une attaque ? Connectez-vous avec la console en passant par l'espace client de PulseHeberg et comparez la clé publique de votre fichier known_hosts avec le contenu du fichier /etc/ssh/ssh_host_ecdsa_key.pub de votre serveur.
Si vous n'avez pas accepté la connexion précédente et que les clés publiques sont identiques, le message affiché est effectivement suspicieux. Dans ce cas "rebooter" votre serveur (reboot) et reconnectez-vous en ssh.
Maintenant que vous avez compris comment le CLIENT authentifie le SERVEUR, voyons comment le SERVEUR fait avec le CLIENT. Pour l'instant lors de notre connexion SSH nous nous authentifions avec un compte utilisateur et un mot de passe.
Nous allons donc voir comment nous authentifier auprès du serveur avec une clé SSH
Première étape : Générer une paire de clés sur notre machine (et pour notre utilisateur) La procédure est assez simple, il suffit juste de choisir quel algorithme de chiffrement nous voulons utiliser. Le plus connu est rsa, mais depuis quelques années, on lui préfèrera ecdsa pour l'authentification. Par souci de compatibilité avec tous les systèmes, nous générerons une paire de clés avec chacun des algorithmes.
Ouvrez une invite de commandes (cmd) ou PowerShell et saisissez simplement la commande suivante : ssh-keygen.exe -t CRYPT (en remplaçant CRYPT par rsa ou ecdsa)
Attention, ne saisissez pas de passphrase (faites juste ENTREE) sinon vous devrez ressaisir cette passphrase à chaque authentification ce qui n'aurait aucun intérêt.
Autre remarque importante, si le système vous dit que la clé existe, ne l'écrasez pas , répondez Non à la question et interrompez la génération de la nouvelle clé. Sauf si bien sur vous êtes certain que la clé existante ne sert à rien (ce dont je doute)
répétez l'opération avec rsa.
La commande est la même (sans le .exe) : ssh-keygen -t ecdsa (et ssh-keygen -t rsa)
Sur votre poste (que ce soit sur MAC ou un PC), les clés que vous venez de générer sont stockées dans le dossier .ssh de votre utilisateur au même endroit que votre fichier known_hosts
On voit ici que pour chaque algorithme de chiffrement il existe 2 fichiers:
Un pour la clé privée que vous ne devez jamais communiqué
Un pour la clé publique (en .pub) que vous allez devoir transmettre au serveur pour qu'il puisse vous authentifier.
Voyons maintenant comment envoyer cette clé publique à votre VPS pour que celui-ci accepte de vous authentifier sans mot de passe.
CAS 1:
Vous êtes sous MAC, utilisez simplement la commande
ssh-copy-id MMI@MMI.mmi-troyes.fr Renseignez votre mot de passe habituel
Relancez la commande ssh MMI@MMI.mmi-troyes.fr, aucun mot de passe ne devrait plus vous être demandé par la suite.
CAS 2: Windows ne disposant pas de la commande ssh-copy-id, nous allons devoir procéder en deux temps: Envoyer la clé sur notre serveur, puis la recopier dans le fichier .ssh/authorized_keys de notre utilisateur (sur le VPS) qui contient les clés publiques autorisées pour l'authentification.
Première phase : On envoie la clé publique dans le dossier de notre utilisateur sur le VPS Remplacez bien MMI par votre identifiant et saisissez votre mot de passe habituel pour ssh
Seconde Phase : On se connecte en SSH sur le serveur comme d'habitude avec le mot de passe. Ne faites pas de sudo -i !! . Ensuite on envoie la clé dans le fichier .ssh/authorized_keys de notre utilisateur.
Vous pouvez vérifier le contenu du fichier .ssh/authorized_keys avec cat ou nano
Pour tester le résultat, fermez votre terminal et reconnectez-vous en SSH sur votre VPS avec ssh MMI@MMI.mmi-troyes.fr , vous ne devriez pas avoir de mot de passe à saisir.
Avant d'installer git sur notre VPS, nous allons d'abord continuer avec la gestion des clés SSH.
Cette clé vous permettra de vous identifier sans mot de passe en utilisant le lien SSH de vos dépôts GitHUB.
Pour authentifier automatiquement votre VPS sur GitHUB et pouvoir récupérer le contenu d'un dépôt par exemple, nous avons aussi besoin d'ajouter la clé de celui-ci dans notre compte GitHUB.
Coté GitHUB, la démarche reste la même (Profil / Settings / SSH Key / New Key / Add Key) Coté serveur, vous devez d'abord générer une clé pour notre utilisateur (sans faire de sudo -i !!)
Ne faites pas de sudo -i avant de saisir les commandes
Ne saisissez pas de passphrase lors de la génération des clés
Ensuite , copiez le résultat de la commande cat dans le formulaire d'ajout des clés de GitHUB.
Avant de poursuivre sur le serveur, revenons vers GitHUB. Voici une check-list de ce que vous devez avoir fait sur votre poste de travail à cette étape de la SAE
Création d'un compte GitHUB
Création d'un dépôt privé GitHUB nommé sae203
Ajout des collaborateurs suivant pour le dépôt sae203 jlandre72 , pgommery , Dannebicque , haraou01, meuzer01 , f-libbrecht
push de votre travail local vers votre dépôt GitHUB sae203
Ajouter la clé publique de votre utilisateur MMI (vps) sur GitHUB
Ne continuez pas si les étapes précédentes ne sont pas effectuées, vous risqueriez de perdre votre travail !!!!
Tout est maintenant prêt pour la mise en place de Git sur votre serveur. Procédons à l'installation
Avant de continuer, nous allons faire une sauvegarde du dossier sae203 existant sur notre serveur avant de le supprimer pour pouvoir cloner le dépôt GitHub sans erreurs
Vous ne devez pas avoir fait sudo -i pour continuer. l'invite de commandes doit être MMI@MMI:~$ (et surtout pas #)
Commençons par initialiser git pour avec votre compte github
Ensuite dans GitHUB, récupérer le lien SSH de votre dépôt sae203
Pour terminer , placez-vous dans le dossier /var/www et clonez le dépôt distant sur votre VPS avec les commandes suivantes
Ne faites pas de copier/coller, remplacez MMI par vos identifiants et surtout le LIEN SSH GITHUB par celui de votre dépôt
Normalement, vous devriez retrouver tous vos fichiers dans votre dossier sae203. Vérifiez que votre site fonctionne avec l'URL: MMI.sae203.ovh
A partir de maintenant, terminé les envois de modifications par Filezilla !!!
Pour continuer la mise à jour de votre site, vous devez utiliser le schéma suivant
Si vous utilisez un IDE tel que PhpStorm ou VSCode, vous avez certainement vu comment envoyer (push) vos données vers le dépôt GitHUB, mais comment faire pour récupérer les données sur votre VPS ? Avec un pull bien sur, mais cela implique d'ouvrir un terminal, de se connecter en ssh, d'aller dans le dossier sae203 et de lancer le git pull manuellement. Et si on essayait d'automatiser un peu tout ça.
Connectez-vous à votre VPS en ssh
Ne faites pas de sudo -i
Ne changez pas de dossier et créez un fichier nommé pullrequest.sh avec le contenu suivant
#!/bin/sh # Automatisation du Pull de la SAE203 cd /var/www/sae203 git pull origin main
Donnez les droits d'exécution sur le fichier avec la commande chmod 750 pullrequest.sh
Terminez votre connexion ssh avec exit
Notre script est prêt à être exécuté. Saisissez la commande
Il ne vous reste plus qu'à tester
Faites une modification d'une de vos pages en local
Envoyez les modifications (commit, push) vers votre dépôt GitHUB
Lancer le script pullrequest.sh pour effectuer un pull vers votre VPS
Ouvrez votre site et constatez que tout est OK
A rendre avant Jeudi 12h30
Tout est OK !! Bravo vous venez de mettre un pied dans le monde des DevOps !! Sur votre VPS, créez un fichier texte /root/MMI-git.txt où MMI est votre identifiant mmi21Xxx Dans ce fichier, mettez le lien https vers votre dépôt github sae203
C'est donc cette méthode (login/mot de passe) qui permet au SERVEUR d'authentifier le CLIENT. Cette méthode est incontournable si la machine du CLIENT est amenée à changer souvent, mais dans le cas ou l'on se connecte toujours de la même machine, cela devient rapidement fastidieux, surtout si l'on a tendance à oublier son mot de passe
Connectez-vous à votre GitHUB. Dans votre profil , sélectionnez Settings puis SSH and GPG Keys Cliquez sur New SSH Key
Ouvrez votre le fichier .ssh/id_ecdsa.pub de votre utilisateur sur votre poste de travail et faites un Copier/Coller de son contenu dans la zone key. Donnez un titre à votre clé et validez par Add SSH Key.
Attention à bien respectez les règles de nommage sous peine d'être pénalisé pour la correction. Le fichier doit être dans /root , se nommer MMI-git.txt et ne contenir qu'une seule ligne du type : et rien d'autre
