Les cours du BTS SIO

Outils pour utilisateurs

Outils du site

Piste :
reseau:debian:clessh

Différences

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

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
reseau:debian:clessh [2025/05/27 22:18] – adminreseau:debian:clessh [2025/05/27 22:24] (Version actuelle) – [Configuration de l'accès SSH] admin
Ligne 25: Ligne 25:
   * En utilisant **mot de passe**, vous utilisez **un seul facteur** d'authentification.   * 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. Ce facteur utilise une solution de chiffrement et est alors considéré comme une **authentification forte** (ANSSI).   * 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).
 +</WRAP>
  
 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. 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.
Ligne 34: Ligne 35:
  
 Pour en savoir plus : https://www.it-connect.fr/chapitres/authentification-ssh-par-cles/ Pour en savoir plus : https://www.it-connect.fr/chapitres/authentification-ssh-par-cles/
- 
-</WRAP> 
  
 ===== La confiance entre client et serveur ===== ===== La confiance entre client et serveur =====
Ligne 62: Ligne 61:
 </code> </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> <code>
Ligne 72: Ligne 71:
 </code> </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. 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 203: Ligne 204:
   * Utilisez **WinSCP** pour vous connecter avec le compte **root** sur votre VM Debian.   * 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**   * Créez dans le dossier **/root** un dossier **.ssh** et un fichier **/root/.ssh/authorized_keys**
 +
 {{ :si7:puttygen_07.png |}} {{ :si7:puttygen_07.png |}}
 +
   * Copiez dans ce fichier le contenu de votre **clé publique**.   * 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**    * Créez dans le dossier du compte **/home/ensbtssio** un dossier **.ssh** et un fichier **/home/ensbtssio/.ssh/authorized_keys** 
reseau/debian/clessh.1748377086.txt.gz · Dernière modification : 2025/05/27 22:18 de admin