Différences

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

--- reseau:debian:clessh [2025/05/27 22:19] – admin
+++ reseau:debian:clessh [2026/01/06 15:34] (Version actuelle) – [Configurer un accès SSH avec une clé SSH depuis un client OpenSSH] admin
@@ Ligne 63: / Ligne 63: @@
 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 71: / 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 150: / Ligne 152: @@
   * utiliser la commande **scp** pour copier le fichier  id_rsa.pub dans le dossier l'utilisateur ;
   * ouvrir une session ssh pour pouvoir ensuite ajouter le contenu du fichier id_rsa.pub dans le fichier authorized_keys :
 <code shell>
 C:> scp .ssh/id_rsa.pub compteutilisateur@adresseip:/home/compteutilisateur/
@@ Ligne 155: / Ligne 158: @@
 $ cat id_rsa.pub >> .ssh/authorized_keys
 </code>
 </WRAP>
@@ Ligne 202: / Ligne 206: @@
   * 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**