Introduction
Dans ce laboratoire, vous acquerrez une expérience pratique de la configuration et de la sécurisation des connexions SSH, une compétence fondamentale pour la gestion de systèmes Linux distants. Vous commencerez par apprendre à accéder à des systèmes distants via SSH, en comprenant l'architecture client-serveur et les commandes de connexion de base. Cela inclut la vérification de l'installation du client SSH, la connexion à un hôte distant, la gestion des invites d'authentification de l'hôte, et la connexion et la déconnexion des systèmes distants.
En vous appuyant sur ces bases, vous aborderez ensuite des sujets plus avancés tels que la génération et l'utilisation de paires de clés SSH pour l'authentification sans mot de passe, la gestion efficace de ces clés avec ssh-agent, et le dépannage des problèmes courants de connexion SSH. Enfin, vous apprendrez à personnaliser les configurations du client SSH pour une meilleure efficacité et à renforcer la sécurité de votre serveur OpenSSH en désactivant la connexion root et l'authentification par mot de passe, garantissant ainsi un accès distant robuste et sécurisé.
Accès aux systèmes distants avec SSH
Dans cette étape, vous apprendrez à accéder à des systèmes distants à l'aide de SSH (Secure Shell). SSH est un protocole réseau cryptographique permettant d'exécuter des services réseau en toute sécurité sur un réseau non sécurisé. Il fournit un canal sécurisé sur un réseau non sécurisé en utilisant une architecture client-serveur, connectant un client SSH à un serveur SSH.
Remarque : Dans cet environnement de laboratoire, certaines fonctionnalités de sécurité, comme les restrictions d'accès root, peuvent déjà être configurées à des fins de sécurité. Ceci est normal et illustre les meilleures pratiques en action.
Tout d'abord, vous vous connecterez au système local via SSH. Cela démontre l'architecture client-serveur SSH même lors de la connexion à la même machine. Vous utiliserez la commande ssh pour vous connecter à localhost.
La syntaxe de base pour ssh est :
ssh [nom_utilisateur]@[nom_hôte_ou_adresse_IP]
Si vous ne spécifiez pas de nom d'utilisateur, SSH tentera de se connecter avec votre nom d'utilisateur local actuel. Dans ce cas, votre nom d'utilisateur local est labex.
Essayons de nous connecter à localhost en utilisant votre nom d'utilisateur actuel :
ssh localhost
Lors de votre première connexion, SSH vous demandera de confirmer l'authenticité de l'hôte. Il s'agit d'une mesure de sécurité pour prévenir les attaques par l'homme du milieu. Tapez oui et appuyez sur Entrée.
L'authenticité de l'hôte 'localhost (127.0.0.1)' ne peut pas être établie.
L'empreinte de la clé ED25519 est SHA256:h5k1mmPFylpxUCsKx+Mf8rN4wOrk9TmyRfzTvGWRm7A.
Cette clé n'est connue sous aucun autre nom.
Êtes-vous sûr de vouloir continuer la connexion (oui/non/[empreinte]) ? oui
Avertissement : Ajouté en permanence 'localhost' (ED25519) à la liste des hôtes connus.
Mot de passe de l'utilisateur 'labex@localhost' :
Vous serez invité à saisir le mot de passe de l'utilisateur labex. Entrez labex et appuyez sur Entrée.
Mot de passe de l'utilisateur 'labex@localhost' :
Dernière connexion : lun 9 juin 01:34:39 2025 depuis 47.251.66.143
[labex@hôte ~]$
Vous êtes maintenant connecté via SSH à localhost. Notez que votre invite peut afficher [labex@localhost ~]$, indiquant que vous êtes connecté via SSH.
Pour vous déconnecter de la session SSH, utilisez la commande exit :
exit
déconnexion
Connexion à localhost fermée.
[labex@hôte ~]$
Maintenant, essayons de nous connecter à localhost en tant qu'utilisateur root. Notez que dans cet environnement, la connexion root peut être désactivée par défaut pour des raisons de sécurité.
ssh root@localhost
Vous serez invité à saisir le mot de passe root. Cependant, vous pourriez rencontrer un message "Permission denied" si la connexion root est désactivée :
Mot de passe de l'utilisateur 'root@localhost' :
Permission refusée, veuillez réessayer.
Mot de passe de l'utilisateur 'root@localhost' :
Permission refusée, veuillez réessayer.
Mot de passe de l'utilisateur 'root@localhost' :
Si la connexion root est désactivée, ce comportement est attendu et illustre une bonne pratique de sécurité. Vous pouvez appuyer sur Ctrl+C pour annuler la tentative de connexion.
SSH peut également être utilisé pour exécuter une seule commande sur un système distant sans ouvrir un shell interactif. Ceci est utile pour des vérifications rapides ou l'automatisation.
Exécutons la commande hostname sur localhost en tant qu'utilisateur labex :
ssh labex@localhost hostname
Vous serez invité à saisir le mot de passe de l'utilisateur labex. Entrez labex et appuyez sur Entrée.
Mot de passe de l'utilisateur 'labex@localhost' :
6846375f1c0e35fea6cb03e6
[labex@hôte ~]$
La commande hostname a été exécutée via SSH, et sa sortie a été affichée sur votre terminal local. Vous n'avez pas été placé dans un shell interactif.
Enfin, explorons comment SSH gère les hôtes connus. Lorsque vous vous connectez à un nouveau serveur SSH, son empreinte de clé publique est ajoutée à votre fichier ~/.ssh/known_hosts. Ce fichier aide votre client SSH à vérifier l'identité du serveur lors des connexions futures.
Vous pouvez afficher le contenu de votre fichier ~/.ssh/known_hosts :
cat ~/.ssh/known_hosts
localhost ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHvl7dcZkvMNOr3cjKjlR2/JgFbGpURThT/bHnLZN6gG
localhost ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCynhy3601o9ZSGZoY0KB/QSonk5ykod2Tb7sCAqVn4ZgTCwd96BhPjJLPNQ6ldNASo1e7EzfT4BUjG5T0ZDRhgaI65qmDwITWipTWUfmYT5XoScyf6NDhcRxYiJwztFEkOvLcPhelS6UXj5Z7HdmYH4Nc5wiF00Wah3Jc0/2CfQsFZCXTn/7Kp8KKbBbPqPzr2R3WIULEacOxx9HKVv+2TvYg/OHZz40hTsr1c68DD7h5PMBNe21YB3HLRRk2LQEC7v7BFD+DCek9GNR66JBjbLDljtwWCaPCY0UntBjjvJ3W2LhX5RDZQHV/iaUSj2tEXnvPt9KSqGfBS91D12dBXyOmWVnTpvvI17BdDkEeefas2Uz4d7Bv/PDxZR6IKkaIGQ/ZnRhSEhBNvfqlBGqkOhRr6jQJK+rQMnsZCT6OEgW7osWzkw5Bs1wY/RNToeQqrRMclqffO9plFI688N2iT86+nxrvBVZg4yMMm2J1lleaBvinXCB8jE6lrtwoAdgk=
localhost ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBKYWY8Ty6TrbQS/0fUljBWuUpkyPCS/5P6ZwxhSYsqjRBIprMANI/JQotZqHYq2w3b2X/n8O+J3/WuIB6XMl1f4=
Ces entrées confirment que votre client a enregistré plusieurs clés publiques pour localhost (ED25519, RSA et ECDSA). Le serveur SSH peut prendre en charge plusieurs types de clés pour la compatibilité. Si l'une de ces clés de serveur change de manière inattendue, SSH vous préviendra, ce qui est une fonctionnalité de sécurité cruciale.
Générer et utiliser des paires de clés SSH pour une authentification sans mot de passe
Dans cette étape, vous apprendrez à générer des paires de clés SSH et à les utiliser pour l'authentification sans mot de passe. L'authentification SSH basée sur les clés est une alternative plus sécurisée et plus pratique à l'authentification par mot de passe. Au lieu de saisir un mot de passe chaque fois que vous vous connectez, vous utilisez une paire de clés cryptographiques : une clé privée (conservée secrètement sur votre machine locale) et une clé publique (placée sur le serveur distant).
Tout d'abord, vous devez générer une paire de clés SSH. Vous utiliserez la commande ssh-keygen à cette fin. Par défaut, ssh-keygen génère une paire de clés RSA et enregistre la clé privée dans ~/.ssh/id_rsa et la clé publique dans ~/.ssh/id_rsa.pub.
Exécutez la commande ssh-keygen :
ssh-keygen
Vous serez invité à saisir quelques options :
Génération de la paire de clés rsa publique/privée.
Entrez le fichier dans lequel enregistrer la clé (/home/labex/.ssh/id_rsa) :
Appuyez sur Entrée pour accepter le chemin par défaut (/home/labex/.ssh/id_rsa).
Entrez une phrase secrète (vide pour aucune phrase secrète) :
Pour ce laboratoire, appuyez deux fois sur Entrée pour laisser la phrase secrète vide. Bien qu'il soit recommandé d'utiliser une phrase secrète dans les scénarios réels pour ajouter une couche de sécurité supplémentaire, nous l'omettons ici pour simplifier et démontrer directement l'authentification sans mot de passe.
Entrez une phrase secrète (vide pour aucune phrase secrète) :
Entrez la même phrase secrète :
Votre identification a été enregistrée dans /home/labex/.ssh/id_rsa
Votre clé publique a été enregistrée dans /home/labex/.ssh/id_rsa.pub
L'empreinte de la clé est :
SHA256:QoV7pNBFu1kafGP3VJhpZuIdr1zc+qamJ1C2YAadgNY labex@6846375f1c0e35fea6cb03e6
L'image randomart de la clé est :
+---[RSA 3072]----+
| . *=o . +.|
| . =oE.o . O. |
| o.++.=..*.+.|
| .o .O+o+o. =|
| ..So + o.+ |
| . . . + |
| . . |
| . o o|
| .=.o |
+----[SHA256]-----+
Vérifiez maintenant que les fichiers de clé ont été créés dans le répertoire ~/.ssh/ :
ls -l ~/.ssh/
total 16
-rw------- 1 labex labex 2622 Jun 9 01:37 id_rsa
-rw-r--r-- 1 labex labex 584 Jun 9 01:37 id_rsa.pub
-rw------- 1 labex labex 825 Jun 9 01:35 known_hosts
-rw-r--r-- 1 labex labex 91 Jun 9 01:35 known_hosts.old
Vous devriez voir id_rsa (votre clé privée) et id_rsa.pub (votre clé publique). Notez les permissions : id_rsa a rw------- (lecture/écriture uniquement pour le propriétaire), ce qui est crucial pour la sécurité. Vous pouvez également voir known_hosts.old, qui est une sauvegarde du fichier known_hosts précédent.
Ensuite, vous devez copier votre clé publique pour activer l'authentification sans mot de passe. La commande ssh-copy-id est conçue à cet effet. Elle ajoute votre clé publique au fichier ~/.ssh/authorized_keys, vous permettant de vous connecter sans mot de passe.
Exécutez la commande ssh-copy-id, en spécifiant l'utilisateur et l'hôte :
ssh-copy-id labex@localhost
Vous serez invité à saisir le mot de passe de l'utilisateur labex. Entrez labex et appuyez sur Entrée.
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/labex/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
labex@localhost's password:
Nombre de clé(s) ajoutée(s) : 1
Essayez maintenant de vous connecter à la machine avec : "ssh 'labex@localhost'"
et vérifiez que seules les clés souhaitées ont été ajoutées.
La sortie de la commande confirme qu'une clé a été ajoutée. Maintenant, essayez de vous connecter à localhost en tant que labex sans fournir de mot de passe :
ssh labex@localhost
Si tout est correctement configuré, vous devriez être connecté via SSH sans être invité à saisir un mot de passe.
Dernière connexion : lun 9 juin 01:37:39 2025 depuis 47.251.66.143
[labex@hôte ~]$
Vous avez correctement configuré l'authentification SSH sans mot de passe à l'aide de paires de clés !
Pour quitter la session distante, tapez exit :
exit
exit
Connexion à localhost fermée.
[labex@hôte ~]$
Gérer les clés SSH avec ssh-agent
Dans cette étape, vous apprendrez à gérer vos clés SSH à l'aide de ssh-agent. ssh-agent est un programme qui s'exécute en arrière-plan et conserve vos clés privées en mémoire. Ceci est particulièrement utile lorsque vos clés privées sont protégées par une phrase secrète. Au lieu de saisir la phrase secrète chaque fois que vous utilisez la clé, vous la saisissez une seule fois lorsque vous ajoutez la clé à ssh-agent, puis l'agent gère l'authentification pour vous pendant la durée de votre session.
Bien que vous ayez généré une clé sans phrase secrète à l'étape précédente, nous allons maintenant créer une nouvelle clé avec une phrase secrète pour démontrer l'utilité de ssh-agent.
Tout d'abord, générez une nouvelle paire de clés SSH avec une phrase secrète. Nous nommerons cette clé id_rsa_passphrase pour la distinguer de la clé par défaut id_rsa.
ssh-keygen -f ~/.ssh/id_rsa_passphrase
Vous serez invité à entrer une phrase secrète. Pour ce laboratoire, utilisez mypassphrase comme phrase secrète.
Génération de la paire de clés rsa publique/privée.
Entrez une phrase secrète (vide pour aucune phrase secrète) : mypassphrase
Entrez la même phrase secrète : mypassphrase
Votre identification a été enregistrée dans /home/labex/.ssh/id_rsa_passphrase
Votre clé publique a été enregistrée dans /home/labex/.ssh/id_rsa_passphrase.pub
L'empreinte de la clé est :
SHA256:BuSxVlJb1lsiUFi2I5DAvyL01fJ5d480LT86dgtcHEg labex@6846375f1c0e35fea6cb03e6
L'image randomart de la clé est :
+---[RSA 3072]----+
| ...=o+=*. E |
| .o.*.=..+ o |
| .=.o o. = . |
| . .+... .. . .|
| . . . +S. + |
| . o ..o . o * .|
| . . . . = * |
| oooo|
| ..+.o|
+----[SHA256]-----+
Remarque : Si vous appuyez accidentellement sur Entrée sans saisir de phrase secrète, la clé sera créée sans phrase secrète. Dans ce cas, vous pouvez supprimer les fichiers et exécuter la commande à nouveau, en veillant à saisir mypassphrase lorsque vous y êtes invité.
Maintenant, copions cette nouvelle clé publique sur localhost afin de pouvoir l'utiliser pour l'authentification.
ssh-copy-id -i ~/.ssh/id_rsa_passphrase.pub labex@localhost
Puisque vous avez déjà configuré l'authentification sans mot de passe avec votre clé par défaut, la commande ne demandera peut-être pas de mot de passe et utilisera votre authentification existante :
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/labex/.ssh/id_rsa_passphrase.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
Number of key(s) added: 1
Essayez maintenant de vous connecter à la machine avec : "ssh 'labex@localhost'"
et vérifiez que seules les clés souhaitées ont été ajoutées.
Maintenant, essayez de vous connecter à localhost avec cette nouvelle clé. Vous devrez spécifier le fichier de clé privée à l'aide de l'option -i.
ssh -i ~/.ssh/id_rsa_passphrase labex@localhost
Si vous avez défini une phrase secrète pour la clé, vous y serez invité. Toutefois, si vous avez accidentellement créé la clé sans phrase secrète (comme indiqué dans la sortie d'exemple), vous serez connecté directement :
Dernière connexion : lun 9 juin 01:39:25 2025 depuis 47.251.66.143
[labex@hôte ~]$
Vous êtes connecté. Maintenant, quittez la session :
exit
exit
Connexion à localhost fermée.
[labex@hôte ~]$
Remarque : Si votre clé n'a pas de phrase secrète, vous pouvez quand même continuer avec la démonstration ssh-agent pour comprendre son fonctionnement, même si elle ne demandera pas de phrase secrète dans ce cas.
Tout d'abord, démarrez ssh-agent dans votre session shell actuelle. La commande eval est utilisée pour définir correctement les variables d'environnement que ssh-agent produit.
eval "$(ssh-agent)"
Agent pid 1024
La sortie affichera l'ID de processus (PID) de ssh-agent.
Ensuite, ajoutez votre clé privée (id_rsa_passphrase) à ssh-agent.
ssh-add ~/.ssh/id_rsa_passphrase
Si votre clé a une phrase secrète, vous y serez invité. Sinon, la clé sera ajoutée directement :
Identity added: /home/labex/.ssh/id_rsa_passphrase (labex@6846375f1c0e35fea6cb03e6)
Maintenant que la clé est ajoutée à ssh-agent, essayez de vous connecter à localhost à nouveau avec la même clé.
ssh -i ~/.ssh/id_rsa_passphrase labex@localhost
Vous devriez pouvoir vous connecter sans être invité à saisir une phrase secrète (que votre clé en ait une ou non, puisqu'elle est maintenant gérée par l'agent) :
Dernière connexion : lun 9 juin 01:39:49 2025 depuis 127.0.0.1
[labex@hôte ~]$
Vous avez réussi à utiliser ssh-agent pour gérer votre clé SSH.
Important : Les variables d'environnement ssh-agent ne sont disponibles que dans la session shell où vous les avez démarrées. Si vous êtes dans une session SSH, vous devez revenir à votre shell local pour utiliser les commandes ssh-add.
Quittez d'abord la session SSH :
exit
exit
Connexion à localhost fermée.
[labex@hôte ~]$
Maintenant, pour voir les clés actuellement chargées dans votre ssh-agent, vous pouvez utiliser ssh-add -l :
ssh-add -l
Si l'agent est en cours d'exécution et a des clés chargées, vous verrez une sortie comme celle-ci :
3072 SHA256:BuSxVlJb1lsiUFi2I5DAvyL01fJ5d480LT86dgtcHEg /home/labex/.ssh/id_rsa_passphrase (RSA)
Cependant, si vous voyez un message d'erreur comme "Impossible d'ouvrir une connexion à votre agent d'authentification", cela signifie que les variables d'environnement de l'agent ne sont pas définies dans votre session actuelle.
Pour supprimer toutes les identités de ssh-agent, utilisez ssh-add -D :
ssh-add -D
Si l'agent est accessible, vous verrez :
Toutes les identités supprimées.
Cependant, si vous voyez "Impossible d'ouvrir une connexion à votre agent d'authentification", cela signifie que l'environnement de l'agent n'est pas disponible dans votre session actuelle.
Maintenant, si vous essayez de vous connecter à nouveau et que votre clé a une phrase secrète, vous y serez invité car la clé a été supprimée de l'agent :
ssh -i ~/.ssh/id_rsa_passphrase labex@localhost
Si votre clé a une phrase secrète, vous verrez :
Entrez la phrase secrète pour la clé '/home/labex/.ssh/id_rsa_passphrase' :
Si votre clé n'a pas de phrase secrète, vous pourrez toujours vous connecter directement. Appuyez sur Ctrl+C pour annuler la tentative de connexion si vous êtes invité à saisir une phrase secrète.
Enfin, pour arrêter le processus ssh-agent, vous pouvez utiliser ssh-agent -k :
ssh-agent -k
Si la variable d'environnement SSH_AGENT_PID n'est pas définie, vous pouvez voir :
SSH_AGENT_PID non défini, impossible de tuer l'agent
Ceci est normal si l'agent a été démarré dans une autre session shell ou si les variables d'environnement n'ont pas été correctement exportées.
Dépanner les problèmes de connexion SSH
Dans cette étape, vous apprendrez à dépanner les problèmes courants de connexion SSH. Lorsque les connexions SSH échouent, il peut être difficile de déterminer le problème exact. La commande ssh propose des options de sortie verbeuses qui peuvent aider à diagnostiquer les problèmes en affichant des informations détaillées sur le processus de connexion.
La commande ssh offre trois niveaux de verbosité : -v, -vv et -vvv. Chaque v supplémentaire augmente la quantité d'informations de débogage affichées.
Commençons par essayer de nous connecter à un port inexistant sur localhost pour démontrer l'échec de la connexion et voir la sortie de débogage.
Tout d'abord, essayons avec -v (verbose) pour nous connecter au port 2222 (qui ne devrait pas être en cours d'exécution) :
ssh -v -p 2222 labex@localhost
Vous verrez une sortie similaire à celle-ci, indiquant que la connexion est refusée :
OpenSSH_8.7p1, OpenSSL 3.0.1 14 déc. 2021
debug1: Lecture des données de configuration /etc/ssh/ssh_config
debug1: Lecture des données de configuration /etc/ssh/ssh_config.d/01-training.conf
debug1: /etc/ssh/ssh_config.d/01-training.conf ligne 1 : Application des options pour *
debug1: Lecture des données de configuration /etc/ssh/ssh_config.d/50-redhat.conf
debug1: /etc/ssh/ssh_config.d/50-redhat.conf ligne 3 : Application des options pour *
debug1: Connexion à localhost [127.0.0.1] port 2222.
ssh : connexion à l'hôte localhost port 2222 : Connexion refusée
Maintenant, essayons avec -vv (plus verbeux) :
ssh -vv -p 2222 labex@localhost
La sortie sera plus détaillée, fournissant des messages de débogage supplémentaires :
OpenSSH_8.7p1, OpenSSL 3.0.1 14 déc. 2021
debug1: Lecture des données de configuration /etc/ssh/ssh_config
debug1: Lecture des données de configuration /etc/ssh/ssh_config.d/01-training.conf
debug1: /etc/ssh/ssh_config.d/01-training.conf ligne 1 : Application des options pour *
debug1: Lecture des données de configuration /etc/ssh/ssh_config.d/50-redhat.conf
debug1: /etc/ssh/ssh_config.d/50-redhat.conf ligne 3 : Application des options pour *
debug2: résolution de "localhost" port 2222
debug2: ssh_connect_direct : entrée
debug1: Connexion à localhost [127.0.0.1] port 2222.
debug1: connexion à l'adresse 127.0.0.1 port 2222 : Connexion refusée
ssh : connexion à l'hôte localhost port 2222 : Connexion refusée
Enfin, essayons avec -vvv (le plus verbeux) :
ssh -vvv -p 2222 labex@localhost
Ce niveau fournit le maximum d'informations de débogage, ce qui peut être accablant mais extrêmement utile pour les problèmes complexes.
OpenSSH_8.7p1, OpenSSL 3.0.1 14 déc. 2021
debug3: ssh_connect_internal : entrée
debug1: Lecture des données de configuration /etc/ssh/ssh_config
debug1: Lecture des données de configuration /etc/ssh/ssh_config.d/01-training.conf
debug1: /etc/ssh/ssh_config.d/01-training.conf ligne 1 : Application des options pour *
debug1: Lecture des données de configuration /etc/ssh/ssh_config.d/50-redhat.conf
debug1: /etc/ssh/ssh_config.d/50-redhat.conf ligne 3 : Application des options pour *
debug2: résolution de "localhost" port 2222
debug2: ssh_connect_direct : entrée
debug1: Connexion à localhost [127.0.0.1] port 2222.
debug1: connexion à l'adresse 127.0.0.1 port 2222 : Connexion refusée
ssh : connexion à l'hôte localhost port 2222 : Connexion refusée
Dans ce cas, l'erreur « Connexion refusée » indique clairement qu'il n'y a pas de serveur SSH en cours d'exécution sur le port 2222.
Maintenant, simulons un problème courant : une clé d'hôte modifiée. Lors de la première connexion à localhost, sa clé publique a été ajoutée à votre fichier ~/.ssh/known_hosts. Si la clé du serveur SSH devait changer (par exemple, en raison d'une reconstruction du serveur ou d'une attaque malveillante), votre client SSH détecterait ce désaccord et refuserait la connexion.
Pour simuler cela, nous allons intentionnellement modifier l'entrée known_hosts pour localhost afin qu'elle soit invalide.
Tout d'abord, ouvrez le fichier ~/.ssh/known_hosts à l'aide de nano :
nano ~/.ssh/known_hosts
Vous verrez plusieurs lignes avec différents types de clés :
localhost ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHvl7dcZkvMNOr3cjKjlR2/JgFbGpURThT/bHnLZN6gG
localhost ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCynhy3601o9ZSGZoY0KB/QSonk5ykod2Tb7sCAqVn4ZgTCwd96BhPjJLPNQ6ldNASo1e7EzfT4BUjG5T0ZDRhgaI65qmDwITWipTWUfmYT5XoScyf6NDhcRxYiJwztFEkOvLcPhelS6UXj5Z7HdmYH4Nc5wiF00Wah3Jc0/2CfQsFZCXTn/7Kp8KKbBbPqPzr2R3WIULEacOxx9HKVv+2TvYg/OHZz40hTsr1c68DD7h5PMBNe21YB3HLRRk2LQEC7v7BFD+DCek9GNR66JBjbLDljtwWCaPCY0UntBjjvJ3W2LhX5RDZQHV/iaUSj2tEXnvPt9KSqGfBS91D12dBXyOmWVnTpvvI17BdDkEeefas2Uz4d7Bv/PDxZR6IKkaIGQ/ZnRhSEhBNvfqlBGqkOhRr6jQJK+rQMnsZCT6OEgW7osWzkw5Bs1wY/RNToeQqrRMclqffO9plFI688N2iT86+nxrvBVZg4yMMm2J1lleaBvinXCB8jE6lrtwoAdgk=
localhost ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBKYWY8Ty6TrbQS/0fUljBWuUpkyPCS/5P6ZwxhSYsqjRBIprMANI/JQotZqHYq2w3b2X/n8O+J3/WuIB6XMl1f4=
Choisissez l'une des lignes à modifier. Pour cet exemple, modifions la clé ED25519 (la première ligne). Modifiez quelques caractères dans la longue chaîne de clé (par exemple, changez le dernier caractère de G en A). Faites attention à ne pas supprimer la ligne entière ou d'autres parties du fichier.
Par exemple, changez :
...ZN6gG
en :
...ZN6gA
Enregistrez le fichier en appuyant sur Ctrl+X, puis Y pour confirmer l'enregistrement et Entrée pour confirmer le nom de fichier.
Essayez maintenant de vous connecter à nouveau à localhost :
ssh labex@localhost
Vous recevrez un avertissement concernant une clé d'hôte modifiée :
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ ATTENTION : L'IDENTIFICATION DE L'HÔTE DISTANT A CHANGÉ ! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IL EST POSSIBLE QUE QUELQU'UN SOIT EN TRAIN DE FAIRE QUELQUE CHOSE DE MALVEILLANT !
Quelqu'un pourrait vous espionner en ce moment (attaque du type « homme du milieu ») !
Il est également possible qu'une clé d'hôte ait été modifiée.
L'empreinte digitale de la clé ED25519 envoyée par l'hôte distant est
SHA256:h5k1mmPFylpxUCsKx+Mf8rN4wOrk9TmyRfzTvGWRm7A.
Veuillez contacter votre administrateur système.
Clé problématique dans /home/labex/.ssh/known_hosts :1
La clé d'hôte ED25519 pour localhost a changé et vous avez demandé une vérification stricte.
Échec de la vérification de la clé d'hôte.
Ceci est un avertissement de sécurité critique. Si vous rencontrez ce problème dans un scénario réel, vous devez déterminer pourquoi la clé d'hôte a changé. S'il s'agit d'un changement légitime (par exemple, une réinstallation du serveur), vous devez supprimer l'ancienne entrée de known_hosts.
Pour corriger cela, vous pouvez soit modifier manuellement ~/.ssh/known_hosts et supprimer la ligne problématique, soit utiliser ssh-keygen -R pour supprimer l'entrée pour localhost.
Utilisons ssh-keygen -R pour supprimer l'entrée incorrecte :
ssh-keygen -R localhost
## Hôte localhost trouvé : ligne 1
## Hôte localhost trouvé : ligne 2
## Hôte localhost trouvé : ligne 3
/home/labex/.ssh/known_hosts mis à jour.
Contenu original conservé sous /home/labex/.ssh/known_hosts.old
Essayez maintenant de vous connecter à nouveau à localhost :
ssh labex@localhost
Vous serez invité à confirmer l'authenticité de l'hôte, comme la première fois que vous vous êtes connecté.
L'authenticité de l'hôte 'localhost (127.0.0.1)' ne peut pas être établie.
L'empreinte digitale de la clé ED25519 est SHA256:h5k1mmPFylpxUCsKx+Mf8rN4wOrk9TmyRfzTvGWRm7A.
Cette clé n'est connue sous aucun autre nom
Êtes-vous sûr de vouloir continuer la connexion (oui/non/[empreinte digitale]) ? oui
Avertissement : Ajout permanent de 'localhost' (ED25519) à la liste des hôtes connus.
Dernière connexion : lun 9 juin 01:40:03 2025 depuis 127.0.0.1
[labex@hôte ~]$
Vous êtes à nouveau connecté avec succès via l'authentification par clé.
Quittez la session :
exit
exit
Connexion à localhost fermée.
[labex@hôte ~]$
Personnaliser les configurations du client SSH
Dans cette étape, vous apprendrez à personnaliser les configurations de votre client SSH à l'aide du fichier ~/.ssh/config. Ce fichier vous permet de définir des alias et des paramètres de connexion spécifiques pour différents hôtes distants, simplifiant vos commandes SSH et les rendant plus cohérentes.
Le fichier ~/.ssh/config est un outil puissant pour gérer vos connexions SSH. Vous pouvez spécifier diverses options telles que le nom d'utilisateur, le fichier de clé privée à utiliser, le numéro de port et même des paramètres plus avancés comme les commandes proxy.
Tout d'abord, créons ou ouvrons le fichier ~/.ssh/config. Si ce fichier n'existe pas, nano le créera.
nano ~/.ssh/config
Ajoutez la configuration suivante au fichier. Cette configuration définit un alias localhost_labex pour se connecter à localhost en tant qu'utilisateur labex, et un alias localhost_root pour se connecter en tant qu'utilisateur root. Elle spécifie également explicitement le IdentityFile pour l'utilisateur labex afin d'utiliser la clé id_rsa générée dans une étape précédente.
Host localhost_labex
HostName localhost
User labex
IdentityFile ~/.ssh/id_rsa
Host localhost_root
HostName localhost
User root
Enregistrez le fichier en appuyant sur Ctrl+X, puis Y pour confirmer l'enregistrement, et Entrée pour confirmer le nom de fichier.
Essayons maintenant de nous connecter à localhost en utilisant ces nouveaux alias.
Connectez-vous en tant qu'utilisateur labex en utilisant l'alias localhost_labex :
ssh localhost_labex
Puisque vous avez configuré IdentityFile ~/.ssh/id_rsa et que id_rsa ne possède pas de phrase secrète, vous devriez être connecté sans être invité à saisir un mot de passe.
Dernière connexion : lun 9 juin 01:54:16 2025 depuis 47.251.66.143
[labex@hôte ~]$
Quittez la session :
exit
exit
Connexion à localhost fermée.
[labex@hôte ~]$
Connectez-vous maintenant en tant qu'utilisateur root en utilisant l'alias localhost_root :
ssh localhost_root
Vous serez invité à saisir le mot de passe de l'utilisateur root. Cependant, comme la connexion root est désactivée dans cet environnement, vous recevrez un message "Permission denied" :
Mot de passe de 'root@localhost' :
Permission refusée, veuillez réessayer.
Mot de passe de 'root@localhost' :
Appuyez sur Ctrl+C pour annuler la tentative de connexion :
^C
Ceci démontre que l'alias de configuration SSH fonctionne, mais que la connexion échoue en raison de la politique de sécurité qui désactive la connexion root.
Comme vous pouvez le constater, l'utilisation du fichier ~/.ssh/config simplifie vos commandes SSH en préconfigurant les paramètres de connexion courants.
Ajoutons une autre entrée pour démontrer la spécification d'un port différent. Alors que localhost utilise le port SSH par défaut (22), cet exemple montre comment le configurer s'il était différent.
Ouvrez à nouveau le fichier ~/.ssh/config :
nano ~/.ssh/config
Ajoutez l'entrée suivante. Cela crée un alias localhost_port_example qui définit explicitement le port sur 2222. (Remarque : localhost n'écoute pas réellement sur le port 2222, donc cette connexion échouera, mais cela démontre la configuration.)
Host localhost_labex
HostName localhost
User labex
IdentityFile ~/.ssh/id_rsa
Host localhost_root
HostName localhost
User root
Host localhost_port_example
HostName localhost
Port 2222
User labex
Enregistrez le fichier.
Essayez maintenant de vous connecter en utilisant l'alias localhost_port_example :
ssh localhost_port_example
Cette connexion échouera car localhost n'écoute pas sur le port 2222, mais cela démontre comment spécifier un port personnalisé dans votre configuration SSH.
ssh : connexion à l'hôte localhost port 2222 : Adresse demandée impossible à assigner
Vous pouvez trouver des explications pour les erreurs courantes à cette adresse :
https://red.ht/support_rhel_ssh
Vous pouvez afficher votre configuration SSH actuelle pour voir tous les hôtes définis :
cat ~/.ssh/config
Host localhost_labex
HostName localhost
User labex
IdentityFile ~/.ssh/id_rsa
Host localhost_root
HostName localhost
User root
Host localhost_port_example
HostName localhost
Port 2222
User labex
Enfin, nettoyons le fichier ~/.ssh/config en supprimant l'entrée localhost_port_example.
Ouvrez le fichier ~/.ssh/config :
nano ~/.ssh/config
Supprimez le bloc Host localhost_port_example. Le fichier devrait ressembler à ceci :
Host localhost_labex
HostName localhost
User labex
IdentityFile ~/.ssh/id_rsa
Host localhost_root
HostName localhost
User root
Enregistrez le fichier.
Comprendre la configuration de sécurité du serveur OpenSSH
Dans cette étape, vous découvrirez les meilleures pratiques de sécurité du serveur OpenSSH en examinant la configuration de sécurité actuelle. Vous comprendrez comment les restrictions de connexion root et les paramètres d'authentification par mot de passe fonctionnent pour protéger votre serveur contre les accès non autorisés.
Note : Dans cet environnement de laboratoire, vous examinerez la configuration de sécurité SSH actuelle et comprendrez les différents paramètres de sécurité. Cette étape se concentre sur la compréhension de ces mesures de sécurité et sur l'apprentissage des meilleures pratiques pour la configuration du serveur SSH.
Comprendre la sécurité de la connexion root
Autoriser la connexion root directe via SSH est généralement déconseillé car le compte root possède des privilèges administratifs complets. Si un attaquant obtient l'accès au compte root, il a un contrôle total sur votre système. Il est plus sûr de se connecter en tant qu'utilisateur régulier, puis d'utiliser sudo pour effectuer des tâches administratives.
Examinons la configuration actuelle de la connexion root et testons son efficacité.
Tout d'abord, connectez-vous via SSH en tant qu'utilisateur labex.
ssh labex@localhost
Vous devriez vous connecter sans mot de passe si votre configuration de clé SSH des étapes précédentes est correcte.
Last login: Mon Jun 9 01:57:27 2025 from 47.251.66.143
[labex@host ~]$
Maintenant, examinons le fichier de configuration du serveur SSH pour comprendre les paramètres de sécurité actuels :
sudo cat /etc/ssh/sshd_config | grep -E "^PermitRootLogin|^#PermitRootLogin"
Cette commande vous montrera le paramètre actuel de PermitRootLogin. Vous devriez voir quelque chose comme :
PermitRootLogin no
Ce paramètre signifie que la connexion root directe via SSH est désactivée, ce qui constitue une meilleure pratique de sécurité.
Testons si la connexion root est effectivement bloquée. Tout d'abord, quittez la session SSH actuelle :
exit
exit
Connection to localhost closed.
[labex@host ~]$
Maintenant, tentez de vous connecter en tant que root à localhost :
ssh root@localhost
Vous devriez voir un message "Permission denied", indiquant que la connexion root directe n'est pas autorisée (cela peut déjà être configuré dans votre environnement).
root@localhost's password:
Permission denied, please try again.
root@localhost's password:
Permission denied, please try again.
root@localhost's password:
Cela confirme que la connexion root est désactivée dans cet environnement, ce qui est la configuration de sécurité souhaitée. Le message "Permission denied" démontre que la mesure de sécurité fonctionne efficacement.
Comprendre la sécurité de l'authentification par mot de passe
Désactiver l'authentification par mot de passe oblige les utilisateurs à s'appuyer sur des méthodes plus sécurisées comme l'authentification par clé SSH. Cela réduit considérablement le risque d'attaques par force brute contre votre serveur.
Examinons le paramètre actuel d'authentification par mot de passe et comprenons son fonctionnement.
Connectez-vous via SSH en tant qu'utilisateur labex (en utilisant votre clé SSH) :
ssh labex@localhost
Last login: Mon Jun 9 01:57:32 2025 from 127.0.0.1
[labex@host ~]$
Tout d'abord, vérifions le paramètre actuel de PasswordAuthentication :
sudo cat /etc/ssh/sshd_config | grep PasswordAuthentication
PasswordAuthentication yes
## PasswordAuthentication. Depending on your PAM configuration,
## PAM authentication, then enable this but set PasswordAuthentication
Comme vous pouvez le voir, PasswordAuthentication yes est actuellement configuré, ce qui signifie que l'authentification par mot de passe est activée. Bien que cela permette aux utilisateurs de s'authentifier avec des mots de passe, cela présente également un risque de sécurité car cela rend le serveur vulnérable aux attaques par force brute de mots de passe.
La sortie montre :
PasswordAuthentication yes- C'est le paramètre actif qui active l'authentification par mot de passe- Les lignes commentées fournissent un contexte supplémentaire sur la configuration PAM
Cette configuration signifie que les utilisateurs peuvent s'authentifier en utilisant à la fois des mots de passe et des clés SSH. Pour une sécurité renforcée, il est recommandé de désactiver l'authentification par mot de passe et de s'appuyer uniquement sur l'authentification par clé SSH.
Quittez la session SSH actuelle :
exit
exit
Connection to localhost closed.
[labex@host ~]$
Maintenant, vérifions que l'authentification par clé SSH fonctionne correctement alors que l'authentification par mot de passe est désactivée :
ssh labex@localhost
Cela devrait réussir sans invite de mot de passe, en utilisant votre clé SSH :
Last login: Mon Jun 9 02:00:22 2025 from 127.0.0.1
[labex@host ~]$
Cela démontre plusieurs concepts de sécurité importants :
- L'authentification par mot de passe est activée (
PasswordAuthentication yes) - Les utilisateurs peuvent se connecter avec des mots de passe et des clés SSH - L'authentification par clé SSH fonctionne correctement - Une méthode d'authentification plus sécurisée est disponible
- Le serveur autorise les deux méthodes d'authentification - Bien que pratique, cela peut présenter des risques de sécurité dus aux attaques par force brute
- La connexion root est désactivée - L'accès administratif nécessite une escalade de privilèges appropriée
Recommandation de sécurité : Pour les environnements de production, envisagez de définir PasswordAuthentication no pour renforcer la sécurité en obligeant les utilisateurs à n'utiliser que l'authentification par clé SSH.
Quittez la session :
exit
exit
Connection to localhost closed.
[labex@host ~]$
Vous avez examiné et compris avec succès la configuration de sécurité du serveur OpenSSH. Le serveur a actuellement la connexion root désactivée (ce qui suit les meilleures pratiques de sécurité) et l'authentification par mot de passe activée (ce qui offre de la flexibilité mais peut nécessiter des considérations de sécurité supplémentaires pour les environnements de production). Vous avez également vérifié que l'authentification par clé SSH fonctionne correctement en tant que méthode d'authentification plus sécurisée.
Résumé
Dans ce laboratoire, les participants ont appris à accéder aux systèmes à l'aide de SSH, en commençant par la vérification de l'installation de openssh-clients et la connexion à localhost via SSH. Ils ont pratiqué l'authentification avec un mot de passe et compris la vérification initiale d'authenticité de l'hôte.
Le laboratoire a ensuite guidé les utilisateurs à travers la génération et l'utilisation de paires de clés SSH pour l'authentification sans mot de passe, la gestion de ces clés avec ssh-agent, et le dépannage des problèmes courants de connexion SSH. Enfin, les participants ont appris à personnaliser les configurations du client SSH et à sécuriser le serveur OpenSSH en désactivant la connexion root et l'authentification par mot de passe, renforçant ainsi leur compréhension des pratiques d'accès distant sécurisé.
