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 des 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'authenticité de l'hôte, ainsi que 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 une authentification sans mot de passe, la gestion efficace de ces clés avec ssh-agent et le dépannage des problèmes de connexion SSH courants. Enfin, vous apprendrez à personnaliser les configurations du client SSH pour améliorer l'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éder à des systèmes distants avec SSH
Dans cette étape, vous apprendrez à accéder à des systèmes distants en utilisant SSH (Secure Shell). SSH est un protocole réseau cryptographique permettant d'exploiter des services réseau de manière sécurisée sur un réseau non sécurisé. Il fournit un canal sécurisé via une architecture client-serveur, reliant un client SSH à un serveur SSH.
Remarque : Dans cet environnement de laboratoire, certaines fonctionnalités de sécurité, comme les restrictions de connexion root, peuvent déjà être configurées à des fins de sécurité. C'est normal et cela démontre les meilleures pratiques en action.
Avant de vous connecter aux systèmes distants, préparez votre environnement de laboratoire en installant les paquets du client et du serveur OpenSSH et en démarrant le service SSH. SSH utilise une architecture client-serveur : le client (ssh) initie les connexions et le serveur (sshd) les accepte. Vous installerez également nano, que vous utiliserez plus tard pour modifier les fichiers de configuration SSH.
Exécutez la commande suivante pour installer les paquets requis. L'option -y confirme automatiquement les invites d'installation des paquets :
sudo dnf install -y openssh-clients openssh-server nano
Démarrez le service SSH et configurez-le pour qu'il démarre automatiquement au démarrage du système :
sudo systemctl start sshd
sudo systemctl enable sshd
Vérifiez que le service SSH est en cours d'exécution :
sudo systemctl status sshd
Vous devriez voir Active: active (running) dans la sortie. Appuyez sur q pour quitter la vue d'état.
Tout d'abord, vous allez vous connecter au système local en utilisant SSH. Cela démontre l'architecture client-serveur SSH même lors d'une 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_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 empêcher les attaques de type « homme du milieu » (man-in-the-middle). Tapez yes et appuyez sur Entrée.
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ED25519 key fingerprint is SHA256:h5k1mmPFylpxUCsKx+Mf8rN4wOrk9TmyRfzTvGWRm7A.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'localhost' (ED25519) to the list of known hosts.
labex@localhost's password:
Vous serez invité à saisir le mot de passe de l'utilisateur labex. Entrez labex et appuyez sur Entrée.
labex@localhost's password:
Last login: Mon Jun 9 01:34:39 2025 from 47.251.66.143
[labex@host ~]$
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
logout
Connection to localhost closed.
[labex@host ~]$
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 :
root@localhost's password:
Permission denied, please try again.
root@localhost's password:
Permission denied, please try again.
root@localhost's password:
Si la connexion root est désactivée, c'est le comportement attendu et cela démontre 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 de shell interactif. C'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.
labex@localhost's password:
6846375f1c0e35fea6cb03e6
[labex@host ~]$
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é basculé dans un shell interactif.
Enfin, explorons comment SSH gère les hôtes connus. Lorsque vous vous connectez à un nouveau serveur SSH, l'empreinte de sa 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 des raisons de compatibilité. Si l'une de ces clés de serveur change de manière inattendue, SSH vous avertira, 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 une authentification sans mot de passe. L'authentification par clé SSH est une alternative plus sécurisée et pratique à l'authentification par mot de passe. Au lieu de taper un mot de passe à chaque connexion, vous utilisez une paire de clés cryptographiques : une clé privée (gardée secrète 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 à cet effet. Par défaut, ssh-keygen crée 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é à choisir quelques options :
Generating public/private rsa key pair.
Enter file in which to save the key (/home/labex/.ssh/id_rsa):
Appuyez sur Entrée pour accepter le chemin de fichier par défaut (/home/labex/.ssh/id_rsa).
Enter passphrase (empty for no passphrase):
Pour ce laboratoire, appuyez deux fois sur Entrée pour laisser la phrase secrète vide. Bien que l'utilisation d'une phrase secrète soit recommandée dans des scénarios réels pour ajouter une couche de sécurité supplémentaire, nous l'ignorerons ici par souci de simplicité et pour démontrer directement l'authentification sans mot de passe.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/labex/.ssh/id_rsa
Your public key has been saved in /home/labex/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:QoV7pNBFu1kafGP3VJhpZuIdr1zc+qamJ1C2YAadgNY labex@6846375f1c0e35fea6cb03e6
The key's randomart image is:
+---[RSA 3072]----+
| . *=o . +.|
| . =oE.o . O. |
| o.++.=..*.+.|
| .o .O+o+o. =|
| ..So + o.+ |
| . . . + |
| . . |
| . o o|
| .=.o |
+----[SHA256]-----+
Maintenant, vérifiez que les fichiers de clés 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 de l'ancien fichier known_hosts.
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 le nom d'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:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'labex@localhost'"
and check to make sure that only the key(s) you wanted were added.
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 configuré correctement, vous devriez être connecté via SSH sans qu'un mot de passe ne vous soit demandé.
Last login: Mon Jun 9 01:37:39 2025 from 47.251.66.143
[labex@host ~]$
Vous avez configuré avec succès l'authentification SSH sans mot de passe en utilisant des paires de clés !
Pour quitter la session distante, tapez exit :
exit
exit
Connection to localhost closed.
[labex@host ~]$
Gérer les clés SSH avec ssh-agent
Dans cette étape, vous apprendrez à gérer vos clés SSH en utilisant ssh-agent. Le ssh-agent est un programme qui s'exécute en arrière-plan et conserve vos clés privées en mémoire. Cela est particulièrement utile lorsque vos clés privées sont protégées par une phrase secrète. Au lieu de taper la phrase secrète à chaque fois que vous utilisez la clé, vous la tapez une fois lorsque vous ajoutez la clé au ssh-agent, puis l'agent gère l'authentification pour vous pendant toute 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é id_rsa par défaut.
ssh-keygen -f ~/.ssh/id_rsa_passphrase
Vous serez invité à saisir une phrase secrète. Pour ce laboratoire, utilisez mypassphrase comme phrase secrète.
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): mypassphrase
Enter same passphrase again: mypassphrase
Your identification has been saved in /home/labex/.ssh/id_rsa_passphrase
Your public key has been saved in /home/labex/.ssh/id_rsa_passphrase.pub
The key fingerprint is:
SHA256:BuSxVlJb1lsiUFi2I5DAvyL01fJ5d480LT86dgtcHEg labex@6846375f1c0e35fea6cb03e6
The key's randomart image is:
+---[RSA 3072]----+
| ...=o+=*. E |
| .o.*.=..+ o |
| .=.o o. = . |
| . .+... .. . .|
| . . . +S. + |
| . o ..o . o * .|
| . . . . = * |
| oooo|
| ..+.o|
+----[SHA256]-----+
Remarque : Si vous appuyez accidentellement sur Entrée sans taper de phrase secrète, la clé sera créée sans. Dans ce cas, vous pouvez supprimer les fichiers et relancer la commande, en veillant à saisir mypassphrase lorsque vous y êtes invité.
Maintenant, copions cette nouvelle clé publique sur localhost afin que vous puissiez l'utiliser pour l'authentification.
ssh-copy-id -i ~/.ssh/id_rsa_passphrase.pub labex@localhost
Comme vous avez déjà configuré l'authentification sans mot de passe avec votre clé par défaut, la commande peut ne pas demander 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
Now try logging into the machine, with: "ssh 'labex@localhost'"
and check to make sure that only the key(s) you wanted were added.
Maintenant, essayez de vous connecter à localhost en utilisant cette nouvelle clé. Vous devrez spécifier le fichier de clé privée en utilisant l'option -i.
ssh -i ~/.ssh/id_rsa_passphrase labex@localhost
Si vous avez défini une phrase secrète pour la clé, vous serez invité à la saisir. Cependant, si vous avez accidentellement créé la clé sans phrase secrète (comme indiqué dans l'exemple de sortie), vous serez connecté directement :
Last login: Mon Jun 9 01:39:25 2025 from 47.251.66.143
[labex@host ~]$
Vous êtes connecté. Maintenant, quittez la session :
exit
exit
Connection to localhost closed.
[labex@host ~]$
Remarque : Si votre clé n'a pas de phrase secrète, vous pouvez toujours continuer avec la démonstration de ssh-agent pour comprendre comment cela fonctionne, même si elle ne demandera pas de phrase secrète dans ce cas.
Tout d'abord, démarrez le ssh-agent dans votre session shell actuelle. La commande eval est utilisée pour définir correctement les variables d'environnement que ssh-agent génère.
eval "$(ssh-agent)"
Agent pid 1024
La sortie affichera l'identifiant de processus (PID) du ssh-agent.
Ensuite, ajoutez votre clé privée (id_rsa_passphrase) au ssh-agent.
ssh-add ~/.ssh/id_rsa_passphrase
Si votre clé a une phrase secrète, vous serez invité à la saisir. Sinon, la clé sera ajoutée directement :
Identity added: /home/labex/.ssh/id_rsa_passphrase (labex@6846375f1c0e35fea6cb03e6)
Maintenant que la clé est ajoutée au ssh-agent, essayez de vous connecter à localhost à nouveau en utilisant la même clé.
ssh -i ~/.ssh/id_rsa_passphrase labex@localhost
Vous devriez pouvoir vous connecter sans qu'une phrase secrète ne vous soit demandée (que votre clé en ait une ou non, puisqu'elle est maintenant gérée par l'agent) :
Last login: Mon Jun 9 01:39:49 2025 from 127.0.0.1
[labex@host ~]$
Vous avez utilisé avec succès ssh-agent pour gérer votre clé SSH.
Remarque importante : Les variables d'environnement ssh-agent ne sont disponibles que dans la session shell où vous l'avez démarré. Si vous êtes dans une session SSH, vous devez quitter pour revenir à votre shell local afin d'utiliser les commandes ssh-add.
Quittez d'abord la session SSH :
exit
exit
Connection to localhost closed.
[labex@host ~]$
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 que des clés sont chargées, vous verrez une sortie comme :
3072 SHA256:BuSxVlJb1lsiUFi2I5DAvyL01fJ5d480LT86dgtcHEg /home/labex/.ssh/id_rsa_passphrase (RSA)
Cependant, si vous voyez un message d'erreur tel que "Could not open a connection to your authentication agent", 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 du ssh-agent, utilisez ssh-add -D :
ssh-add -D
Si l'agent est accessible, vous verrez :
All identities removed.
Cependant, si vous voyez "Could not open a connection to your authentication agent", 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 serez invité à la saisir 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 :
Enter passphrase for key '/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 une phrase secrète vous est demandée.
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 pourriez voir :
SSH_AGENT_PID not set, cannot kill agent
C'est normal si l'agent a été démarré dans une session shell différente 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 à résoudre les problèmes de connexion SSH courants. Lorsque les connexions SSH échouent, il peut être difficile de localiser le problème exact. La commande ssh fournit des options de sortie verbeuse qui peuvent aider à diagnostiquer les problèmes en affichant des informations détaillées sur le processus de connexion.
La commande ssh propose 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 tenter 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, essayez avec -v (verbeux) pour vous connecter au port 2222 (qui ne devrait pas être actif) :
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 Dec 2021
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/01-training.conf
debug1: /etc/ssh/ssh_config.d/01-training.conf line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: /etc/ssh/ssh_config.d/50-redhat.conf line 3: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 2222.
ssh: connect to host localhost port 2222: Connection refused
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 Dec 2021
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/01-training.conf
debug1: /etc/ssh/ssh_config.d/01-training.conf line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: /etc/ssh/ssh_config.d/50-redhat.conf line 3: Applying options for *
debug2: resolving "localhost" port 2222
debug2: ssh_connect_direct: entering
debug1: Connecting to localhost [127.0.0.1] port 2222.
debug1: connect to address 127.0.0.1 port 2222: Connection refused
ssh: connect to host localhost port 2222: Connection refused
Enfin, essayez avec -vvv (le plus verbeux) :
ssh -vvv -p 2222 labex@localhost
Ce niveau fournit la quantité maximale d'informations de débogage, ce qui peut être écrasant mais extrêmement utile pour les problèmes complexes.
OpenSSH_8.7p1, OpenSSL 3.0.1 14 Dec 2021
debug3: ssh_connect_internal: entering
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/01-training.conf
debug1: /etc/ssh/ssh_config.d/01-training.conf line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: /etc/ssh/ssh_config.d/50-redhat.conf line 3: Applying options for *
debug2: resolving "localhost" port 2222
debug2: ssh_connect_direct: entering
debug1: Connecting to localhost [127.0.0.1] port 2222.
debug1: connect to address 127.0.0.1 port 2222: Connection refused
ssh: connect to host localhost port 2222: Connection refused
Dans ce cas, l'erreur Connection refused indique clairement qu'aucun serveur SSH n'est 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 étape, vous vous êtes connecté à localhost et sa clé publique a été ajoutée à votre fichier ~/.ssh/known_hosts. Si la clé du serveur SSH venait à changer (par exemple, en raison d'une reconstruction du serveur ou d'une attaque malveillante), votre client SSH détecterait cette incohérence et refuserait de se connecter.
Pour simuler cela, nous allons intentionnellement modifier l'entrée known_hosts pour localhost afin de la rendre invalide.
Tout d'abord, ouvrez le fichier ~/.ssh/known_hosts en utilisant 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, remplacez le dernier caractère G par A). Faites attention à ne pas supprimer toute la ligne ou d'autres parties du fichier.
Par exemple, remplacez :
...ZN6gG
par :
...ZN6gA
Enregistrez le fichier en appuyant sur Ctrl+X, puis Y pour confirmer l'enregistrement, et Entrée pour confirmer le nom du fichier.
Maintenant, essayez de vous connecter à localhost à nouveau :
ssh labex@localhost
Vous recevrez un avertissement concernant une clé d'hôte modifiée :
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:h5k1mmPFylpxUCsKx+Mf8rN4wOrk9TmyRfzTvGWRm7A.
Please contact your system administrator.
Add correct host key in /home/labex/.ssh/known_hosts to get rid of this message.
Offending key in /home/labex/.ssh/known_hosts:1
ED25519 host key for localhost has changed and you have requested strict checking.
Host key verification failed.
Il s'agit d'un avertissement de sécurité critique. Si vous rencontrez cela dans un scénario réel, vous devez enquêter sur la raison pour laquelle la clé d'hôte a changé. S'il s'agit d'un changement légitime (par exemple, 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 incriminée, 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
## Host localhost found: line 1
## Host localhost found: line 2
## Host localhost found: line 3
/home/labex/.ssh/known_hosts updated.
Original contents retained as /home/labex/.ssh/known_hosts.old
Maintenant, essayez de vous connecter à localhost à nouveau. Vous serez invité à confirmer l'authenticité de l'hôte, tout comme lors de votre toute première connexion.
ssh labex@localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ED25519 key fingerprint is SHA256:h5k1mmPFylpxUCsKx+Mf8rN4wOrk9TmyRfzTvGWRm7A.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'localhost' (ED25519) to the list of known hosts.
Last login: Mon Jun 9 01:40:03 2025 from 127.0.0.1
[labex@host ~]$
Vous êtes maintenant reconnecté avec succès en utilisant l'authentification par clé.
Quittez la session :
exit
exit
Connection to localhost closed.
[labex@host ~]$
Personnaliser les configurations du client SSH
Dans cette étape, vous apprendrez à personnaliser les configurations de votre client SSH en utilisant le 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 ainsi 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. S'il 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 l'IdentityFile pour que l'utilisateur labex utilise la clé id_rsa générée lors d'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 du fichier.
Maintenant, essayons de nous connecter à localhost en utilisant ces nouveaux alias.
Connectez-vous en tant que labex en utilisant l'alias localhost_labex :
ssh localhost_labex
Comme vous avez configuré IdentityFile ~/.ssh/id_rsa et que id_rsa n'a pas de phrase secrète, vous devriez être connecté sans qu'un mot de passe ne vous soit demandé.
Last login: Mon Jun 9 01:54:16 2025 from 47.251.66.143
[labex@host ~]$
Quittez la session :
exit
exit
Connection to localhost closed.
[labex@host ~]$
Maintenant, connectez-vous en tant que 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" :
root@localhost's password:
Permission denied, please try again.
root@localhost's password:
Appuyez sur Ctrl+C pour annuler la tentative de connexion :
^C
Cela 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. Bien que localhost utilise le port SSH par défaut (22), cet exemple montre comment vous le configureriez 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.
Maintenant, essayez 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: connect to host localhost port 2222: Cannot assign requested address
You can find some explanations for typical errors at this link:
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.
Remarque : 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 dispose de privilèges administratifs complets. Si un attaquant accède 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 PermitRootLogin actuel. 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 est une bonne pratique de sécurité.
Testons si la connexion root est réellement 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 force 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 d'authentification par mot de passe actuel et comprenons comment il fonctionne.
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 PasswordAuthentication actuel :
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 sur les 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 demande 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 poser des risques de sécurité liés aux attaques par force brute
- La connexion root est désactivée - L'accès administratif nécessite une élévation 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 forçant les utilisateurs à utiliser uniquement 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 à des systèmes en utilisant SSH, en commençant par vérifier l'installation de openssh-clients et en se connectant à localhost via SSH. Ils se sont entraînés à s'authentifier avec un mot de passe et ont compris la vérification initiale de l'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 une authentification sans mot de passe, la gestion de ces clés avec ssh-agent et le dépannage des problèmes de connexion SSH courants. 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, améliorant ainsi leur compréhension des pratiques d'accès distant sécurisé.
