Différences

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

--- reseau:debian:clessh [2025/05/27 22:18] – [Présentation] admin
+++ reseau:debian:clessh [2025/05/27 22:24] (Version actuelle) – [Configuration de l'accès SSH] admin
@@ Ligne 35: / Ligne 35: @@
 Pour en savoir plus : https://www.it-connect.fr/chapitres/authentification-ssh-par-cles/
-</WRAP>
 ===== La confiance entre client et serveur =====
@@ Ligne 63: / 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 73: / 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 204: / 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**