Différences

Ci-dessous, les différences entre deux révisions de la page.

--- reseau:debian:clessh [2025/01/08 15:19] – techer.charles_educ-valadon-limoges.fr
+++ reseau:debian:clessh [2025/05/27 22:24] (Version actuelle) – [Configuration de l'accès SSH] admin
@@ Ligne 4: / Ligne 4: @@
 ===== Présentation =====
-Pour administrer un serveur Linux, vous pouvez utiliser le compte **root** ou, ce qui est fortement conseillé, un compte que vous avez créé et à qui vous avez permis une **élévation de privilèges**.
+Pour administrer un serveur Linux, vous pouvez utiliser le compte **root** ou, ce qui est fortement conseillé, un compte que vous avez créé et à qui vous avez permis une **élévation de privilèges** pour permettre l'utilisation de **sudo**.
 Si vous gérez un autre serveur, il est également fortement conseillé d'utiliser **un mot de passe différent**. Cette solution n'est **pas satisfaisante et peu sécurisée** si vous devez gérer de nombreux serveurs.
@@ Ligne 13: / Ligne 13: @@
   * utiliser des **clés SSH publique**.
-Vous aller configurer le compte **root** ou le compte linux que vous avez créé afin de permettre d'ouvrir une session en utilisant une **clé publique SSH**.
+Vous aller configurer le compte linux que vous avez créé afin de permettre d'ouvrir une session en utilisant une **clé publique SSH** :
-Vous utiliserez **votre propre clé publique SSH** pour vous connecter.
+  * Vous utiliserez **votre propre clé publique SSH** pour vous connecter.
-Vous permettrez à l'enseignant de se connecter en simple utilisateur avec un compte que vous devez créer et appeler ensbtssio avec sa **clé publique SSH**.
+  * Vous permettrez à l'enseignant de se connecter en simple utilisateur avec un compte que vous devez créer et appeler ensbtssio avec sa **clé publique SSH**.
-Après la création de votre **couple de clés Privée/publique**, communiquez aux enseignants votre **clé publique** dans le dossier partagé Classe.
+Après la création de votre **couple de clés Privée/publique**, communiquez aux enseignants votre **clé publique** dans le dossier partagé de l'équipe Teams.
 Votre clé publique sera rajoutée à la page des clés SSH du BTS SIO à la page :
@@ Ligne 24: / Ligne 24: @@
 <WRAP center round info>
   * En utilisant **mot de passe**, vous utilisez **un seul facteur** d'authentification.
-  * En utilisant une **clé publique SSH,** vous utilisez également **un seul facteur** d'authentification.
+  * En utilisant une **clé publique SSH,** vous utilisez également **un seul facteur** d'authentification. Ce facteur utilise une solution de chiffrement et est alors considéré comme une **authentification forte** (ANSSI).
-Cependant, vous pouvez utiliser la **même clé publique SSH sur plusieurs serveurs** en ne retenant qu'un seul mot de passe, celui de la passphrase de votre clé privée.
+</WRAP>
-En général on **désactive** ensuite l'authentification par mot de passe sur les serveurs afin de n'autoriser que l'authentification par clé SSH publique.
+Vous pouvez utiliser la **même clé publique SSH sur plusieurs serveurs** en ne retenant qu'un seul mot de passe, celui de la passphrase qui protège de votre clé privée.
-Pour en savoir plus : https://www.it-connect.fr/chapitres/authentification-ssh-par-cles/
+<WRAP center round info>
+Après avoir configuré une authentification avec une clé SSH publique, il est conseillé de **désactiver** l'authentification par mot de passe sur les serveurs.
 </WRAP>
-===== La confiance entre client et serveur =====
+Pour en savoir plus : https://www.it-connect.fr/chapitres/authentification-ssh-par-cles/
-Les clefs SSH permettent aussi de garantir l'identité d'un interlocuteur sur le réseau sans avoir à échanger de secret partagé.
+===== La confiance entre client et serveur =====
-Le client qui se connecte à un serveur par SSH doit avoir confiance en l'identité de ce serveur (éviter les attaques de type attaque de l'homme du milieu).
-Pour accorder l'accès de client au système, le serveur doit avoir confiance en l'identité du client.
+Les clefs SSH permettent aussi de garantir l'identité d'un interlocuteur sur le réseau sans avoir à échanger de secret partagé :
+  * Le client qui se connecte à un serveur par SSH doit avoir **confiance en l'identité de ce serveur** (éviter les attaques de type attaque de l'**homme du milieu**).
+  * Pour accorder l'accès de client au système, le serveur doit avoir **confiance en l'identité du client**.
 ==== Authentification du client par le serveur ====
-Pour que le serveur fasse confiance au client qui tente de se connecter, l'administrateur du système doit placer la clef SSH publique de chaque utilisateur⋅rice dans le fichier ~/.ssh/authorized_keys du compte.
+Pour que le serveur fasse confiance au client qui tente de se connecter, l'administrateur du système doit placer la **clef SSH publique de chaque utilisateur⋅rice** dans le fichier **~/.ssh/authorized_keys** du compte.
-Lors de la connexion au serveur, le client utilise la clef SSH privée de l'utilisateur⋅rice et le serveur peut vérifier l'authenticité grâce à la clef publique correspondante conservée dans le fichier ~/.ssh/authorized_keys du compte auquel le client tente de se connecter.
+Lors de la connexion au serveur, le client utilise la clef SSH privée de l'utilisateur⋅rice et le serveur peut vérifier l'authenticité grâce à la clef publique correspondante conservée dans le fichier **~/.ssh/authorized_keys** du compte auquel le client tente de se connecter.
 ==== Authentification du serveur par le client ====
@@ Ligne 60: / Ligne 61: @@
 </code>
-Si l'utilisateur⋅rice accepte de se connecter à ce serveur, le client va enregistrer la clef du serveur dans son fichier ~/.ssh/known_hosts (indexée avec une valeur de hashage calculée avec le nom du serveur tel qu'il a été donné au client SSH).
+Si l'utilisateur⋅rice accepte de se connecter à ce serveur, le client va enregistrer la clef du serveur dans son fichier **~/.ssh/known_hosts** (indexée avec une valeur de hashage calculée avec le nom du serveur tel qu'il a été donné au client SSH).
-La commande ssh-keygen -F <hôte> permet de rechercher la clef d'une machine dans le fichier ~/.ssh/known_hosts.
+La commande **ssh-keygen -F <hôte>** permet de rechercher la clef d'une machine dans le fichier **~/.ssh/known_hosts**.
 <code>
@@ Ligne 70: / Ligne 71: @@
 </code>
-Lors des connexions suivantes, le client va rechercher de la même façon dans le fichier ~/.ssh/known_hosts la clef publique du serveur. Si la clef publique ainsi conservée correspond bien à la clef privée utilisée par le serveur, le client va faire confiance au serveur et procéder ensuite à sa propre authentification. Si ce n'est pas le cas, le client interrompt la connexion et affiche à l'utilisateur⋅rice un message lui indiquant que le serveur auquel il ou elle tente de se connecter n'a plus la même clef SSH que lors de sa dernière connexion, ce qui indique que le serveur n'est peut-être pas celui auquel il ou elle souhaite se connecter.
+Lors des connexions suivantes, le client va rechercher de la même façon dans le fichier **~/.ssh/known_hosts** la clef publique du serveur :
+  * Si la clef publique ainsi conservée correspond bien à la clef privée utilisée par le serveur, le client va faire confiance au serveur et procéder ensuite à sa propre authentification.
+  * Si ce n'est pas le cas, le client interrompt la connexion et affiche à l'utilisateur⋅rice un message lui indiquant que le serveur auquel il ou elle tente de se connecter n'a plus la même clef SSH que lors de sa dernière connexion, ce qui indique que le serveur n'est peut-être pas celui auquel il ou elle souhaite se connecter.
-On remarque qu'une faiblesse du protocole existe à ce niveau puisqu'à la première connexion, l'utilisateur⋅rice qui accepte aveuglément la clef SSH du serveur prend le risque de se connecter à un serveur qui n'est pas celui qu'il croit être.
+On remarque qu'une **faiblesse du protocole** existe à ce niveau puisqu'à la première connexion, l'utilisateur⋅rice qui accepte aveuglément la clef SSH du serveur prend le risque de se connecter à un serveur qui n'est pas celui qu'il croit être.
 Ce risque peut être écarté si les clefs publiques des serveurs sont distribuées par d'autres moyens aux utilisateur⋅rice⋅s pour les ajouter à leur fichier known_hosts, leur permettant ainsi d'authentifier le serveur dès leur première connexion.
@@ Ligne 118: / Ligne 121: @@
 <WRAP center round info>
-Un autre fichier **know_hosts** sera ensuite créé dans le dossier **.ssh** afin de contenir **les clés publiques des serveurs** sur lesquels vous vous êtes authentifié avec un mot de passe ou une clé SSH publique.
+Un autre fichier **know\_hosts** sera ensuite créé dans le dossier **.ssh** afin de contenir **les clés publiques des serveurs** sur lesquels vous vous êtes authentifié avec un mot de passe ou une clé SSH publique.
   * Pour retrouver l'entrée d'un nom d’hôte connu dans known_hosts:
@@ Ligne 136: / Ligne 139: @@
   * Copiez ensuite votre clé publique sur le serveur auquel vous souhaitez accéder avec la clé SSH.
 <code shell>
 $ ssh-copy-id utilisateur@IP_ordinateur_cible
@@ Ligne 200: / Ligne 204: @@
   * Utilisez **WinSCP** pour vous connecter avec le compte **root** sur votre VM Debian.
   * Créez dans le dossier **/root** un dossier **.ssh** et un fichier **/root/.ssh/authorized_keys**
 {{ :si7:puttygen_07.png |}}
   * Copiez dans ce fichier le contenu de votre **clé publique**.
   * Créez dans le dossier du compte **/home/ensbtssio** un dossier **.ssh** et un fichier **/home/ensbtssio/.ssh/authorized_keys**