+

Module “Linux
Administration
Option
and Security” INDP3
Cyber Security
and Defense (CySed)

Élaboré par:
Wiem Zemzem

2023-2024
+ 2
Chapitre 3

Configuration
et sécurisation de SSH
+ 3
Secure Shell (ssh)

◼ Le paquetage OpenSSH fournit le protocole Secure Shell ou SSH.

◼ Le protocole SSH permet aux systèmes de communiquer de

manière chiffrée et sécurisée sur un canal d’un réseau non
sécurisé.

◼ Son démon de service est sshd.

◼ Le port 22 est le port par défaut du service SSH.

◼ La commande ssh peut exécuter une session sur un système

distant.
+ 4
Type d’accès au système linux
+ 5
PuTTY

◼ PuTTY est un émulateur de terminal pour Windows

permettant la connexion à une machine distante par le
protocole ssh.

◼ Avec ce logiciel, vous pouvez travailler, depuis votre

ordinateur personnel, sur une machine Linux, en mode
ligne de commandes. PuTTY ne permet pas l'affichage
graphique.

◼ [Link]

◼ [Link]
install-putty-on-windows/
+ 6
Putty Configuration
+ 7
Connexion via Putty
+ La commande w 8

◼ La commande w affiche une liste des utilisateurs actuellement

connectés au système.
◼ Elle affiche également l’emplacement du système distant et les
commandes que l’utilisateur a exécutées.
◼ Toutes les sessions de connexion sont associées à un périphérique de
terminal (TTY).

◼ Si le nom du périphérique est pts/N, alors il s’agit d’une session de

connexion à distance.

◼ S’il est ttyN, l’utilisateur est connecté en direct à un périphérique de

terminal
+ 9
Contrôle de connexion
cas des machines redhat
◼ Ouvrir workstation

◼ Taper w→ une session student en direct sur workstation

◼ Se connecter à servera ssh student@servera

◼ Taper w → une session student à distance sur servera

◼ Ouvrir la machine servera dans un nouveau onglet et se

connecter en tant que student

◼ Taper w → deux sessions student dans servera: 1 à distance

et 1 en direct
+ 10
Contrôle de connexion
cas de connexion à partir de windows

Windows (adresse IP de la machine windows)

+ Exemples de Secure Shell 11

◼ Se connecter sur le serveur distant hosta en utilisant le même nom

d’utilisateur que l’utilisateur local actuel → le système distant
demande de s’ authentifier avec le mot de passe de l’utilisateur
developer1.

◼ exit: Se déconnecter du système distant

+ Exemples de Secure Shell 12

◼ Se connecter sur le serveur distant hosta en utilisant le nom

d’utilisateur developer2→ besoin de s’authentifier avec le mot de
passe de l’utilisateur developer2
+ 13

Identification des utilisateurs distants

❑ La sortie montre que l’utilisateur developer2 s’est connecté au système sur le

pseudo-terminal 0 à 16:13 aujourd’hui à partir de l’hôte avec l’adresse IP
[Link], et a été inactif lors d’une invite du shell pendant sept minutes
et trente secondes.

❑ La sortie montre également que l’utilisateur developer1 s’est connecté au

système sur le pseudo-terminal 1 et a été inactif pendant les trois dernières
secondes qui ont suivi l’exécution de la commande w.
+ 14
Clés d’hôte SSH (1)
◼ SSH sécurise les communications par chiffrement à clé
publique.

◼ Lorsqu’un client SSH se connecte à un serveur SSH, le serveur

envoie une copie de sa clé publique au client. Cette clé permet
de configurer le chiffrement sécurisé du canal de
communication et d’authentifier le système du client.

◼ Lorsqu’un utilisateur utilise la commande ssh pour se

connecter à un serveur SSH, la commande recherche une copie
de la clé publique du serveur dans ses fichiers hôtes locaux
connus.
+ Clés d’hôte SSH (2) 15

◼ Les fichiers se trouve dans :

◼ Le fichier ~/.ssh/known_hosts dans le répertoire personnel de
chaque utilisateur.

◼ $ cat ~/.ssh/known_hosts

◼ Si le client possède une copie de la clé, la commande ssh compare la

clé des fichiers hôtes connus de ce serveur à celle qu’il a reçue.
+ Clés d’hôte SSH (3) 16

◼ Si les clés ne correspondent pas, le client suppose que le trafic

réseau vers le serveur est douteux, et demande à l’utilisateur de
confirmer s’il souhaite poursuivre la connexion.
 1ere connexion de student à servera depuis serverb

+ 17

Fermeture de la session student@servera

2eme connexion de student à serverb depuis servera

La suppression du fichier /home/student/.ssh/known_hosts de la machine serverb

amène ssh à perdre les identités enregistrées des systèmes distants.
+ 18
Configurer et sécuriser ssh
◼ Le protocole SSH permet aux systèmes de communiquer de manière chiffrée et
sécurisée.

◼ Les communications par SSH sont toujours cryptées mais il est possible d’ajouter
d’autres mesures de sécurité.

◼ Le démon sshd fournit le service OpenSSH. Vous pouvez configurer le service en

modifiant le fichier /etc/ssh/sshd_config.

◼ Les configurations les plus courantes que l'administrateur peut adapter pour
sécuriser SSH:
1. Configurer IDLE Timeout Interval
2. Désactiver root login
3. Limiter l'accès des utilisateurs à ssh
4. Utiliser d’autres ports ≠ 22
5. SSH-keys - Accès aux serveurs distants sans mot de passe
 +Configurer IDLE Timeout Interval 19

1. Passer en mode root et modifier le fichier sshd_config

2. modifier le fichier sshd_config

3. Redémarraer le daemon sshd

→ Déconnexion automatique après 600 secondes (=10 minutes) d’inactivité

→ Le système a pris en considération la mise à jour et il n’y a pas de fautes.
→ Pour annuler la mise à jour:
+ 20
Désactiver root login
◼ L’utilisateur root dispose de privilèges illimités, sa compromission peut
donc causer un maximum de dommages au système.

◼ Le nom d’utilisateur root existe par défaut sur chaque système Linux. Il
suffit à un intrus potentiel de ne deviner que son mot de passe, au lieu
d’une combinaison valide d’un nom d’utilisateur et d’un mot de passe.
Ce scénario facilite les choses pour un attaquant.

◼ La désactivation du login root empêche tout utilisateur de se connecter

à distance au système avec le compte root.
◼ Passer en mode root
◼ Editer le fichier sshd_config et changer PermitRootLogin yes par no
◼ PermitRootLogin no
◼ #systemctl restart sshd
+ 21
Interdire la connexion par mot de
passe
◼ Pour root uniquement
◼ Passer en mode root

◼ Editer le fichier sshd_config et changer PermitRootLogin

◼ PermitRootLogin prohibit-password
◼ #systemctl restart sshd

◼ Pour un client ssh:

◼ Passer en mode root

◼ Editer le fichier sshd_config et changer PasswordAuthentication

◼ PasswordAuthentication no
◼ #systemctl restart sshd
+ 22
Limiter l'accès des utilisateurs à
ssh
◼ Pour offrir un autre niveau de sécurité, il est possible de ne
permettre l’utilisation du ssh qu’ à certains utilisateurs ayant
besoin d’accèder à distance.
◼ Passer en mode root
◼ Editer le fichier /etc/ssh/sshd_config et taper:
◼ AllowUsers user1 user2

◼ #systemctl restart sshd

+ 23

Limiter l'accès des utilisateurs à ssh (2)

+ Utiliser d’autres ports ≠ 22 24
◼ Par défaut, ssh fonctionne via le port 22. La plupart des pirates qui
sont à la recherche de serveurs openssh attaqueront le port 22
et le fait de le modifier peut enforcer la sécurité du système.
◼ Passer en mode root
◼ Editer le fichier sshd_config et enlever # de la ligne:
◼ Port 22 et changer le numéro ( choisir entre 1024 et 65536)

◼ #systemctl restart sshd

◼ # ssh root@IP_address_of_the_server -p NewPort

◼ Il faut s’assurer que le nouveau port n’est pas utiliser par d’autres
services [voir ce lien]
◼ Liste des ports est dans le fichier /etc/services.
+ 25
SSH-keys - Accès aux serveurs
distants sans mot de passe
◼ générer une clé SSH →Deux raisons:

1. La connexion répétitive, c'est-à-dire que si vous avez une

machine Linux A et que vous vous connectez à la machine Linux
B plusieurs fois par jour et vous ne voulez pas entrer un nom
d'utilisateur et un mot de passe à chaque fois; vous allez
générer une clé SSH.

2. L'automatisation via des scripts. Si vous avez des scripts

exécutés sur votre serveur A et que vous avez besoin de les
exécuter sur un serveur B de manière automatisé. A chaque
execution de A à B, il vous demandera un nom d'utilisateur et
un mot de passe, Et bien sûr, c'est une tâche journalière et
vous ne voulez pas avoir aucun type d'interaction avec elle.
C'est pourquoi vous créez une clé SSH. Ainsi, l'automatisation
se fera d'elle-même sans aucune interaction humaine.
+ Configuration de l’authentification par clé SSH 26

◼ Vous pouvez configurer votre compte pour un accès sans mot de

passe aux serveurs SSH sur lesquels l’authentification par clé est
activée, conformément au chiffrement à clé publique (PKI).

◼ Pour préparer votre compte, générez une paire de fichiers de clés

liés au chiffrement.
◼ Une clé qui est privée et n’appartient qu’à vous. La clé privée
correspond aux informations d’authentification et doit être
stockée de manière sécurisée.
◼ La seconde clé est votre clé publique associée, qui n’est pas
secrète. La clé publique est copiée sur votre compte sur les
serveurs auxquels vous accéderez à distance et vérifie votre
utilisation de votre clé privée.
+ Configuration de l’authentification par clé SSH 27

◼ Lorsque vous vous connectez à votre compte sur un serveur distant, ce

dernier utilise votre clé publique pour chiffrer un message de demande
d’authentification et l’envoyer à votre client SSH. Votre client SSH doit
ensuite prouver qu’il peut déchiffrer ce message, ce qui montre que
vous disposez de la clé privée associée. Si cette vérification réussit,
votre demande est alors approuvée et votre accès est autorisé sans
mot de passe.

◼ Les mots de passe sont faciles à apprendre et voler, mais les clés
privées stockées en toute sécurité sont plus difficiles à compromettre
+ Génération de clés SSH 28

◼ Pour accéder à une machine distante sans indiquer username +

password, il faut générer des clés

◼ Keys sont générées soit par root (pour root) soit par un simple
user (pour ce user)
+ Machine A: LinuxAdministration 29
+ 30
Machine B: Redhat8

L’adresse IP du client est [Link]

+ 31
Login from A to B using password
+ 32
Login from A to B without password

◼ Utilisez la commande ssh-keygen pour créer une paire de

clés. Par défaut, la commande ssh-keygen enregistre vos clés
privées et publiques dans les fichiers ~/.ssh/id_rsa et
~/.ssh/id_rsa.

◼ Client: Machine A: LinuxAdministration

+ 33
Step1: ssh-keygen

Copier la clé publique

dans la machine distante
+ Step2: Copier la clé publique 34

dans la machine distante B

◼ Besoin d’entrer le mot de passe du client distant ( mot de passe du
student dans la machine B) juste pour la 1ere tentative de connexion
+ Vérification 35

Machine A

Machine B distante:
+ Step 3: accès distant 36

Machine distante :” Ah! je

connais votre clé donc
vous pouvez vous
connecter sans mot de
passe!”
+ Step 3: accès distant 37
Machine A

Machine B distante: la session ouverte est relative à l’utilisateur wiem

+ 38
Travaux à rendre
◼ Red Hat System Administration I (RH124)

◼ Chapter 10: Configuration et sécurisation de SSH

◼ Section 10.2: Exercice guidé: Accès à la ligne de commande distante
◼ Section 10.4: Exercice guidé: Configuration de l’authentification par
clé SSH.
◼ Section 10.6: Exercice guidé: Personnalisation de la configuration du
service OpenSSH
◼ Section 10.7: Open Lab: Configuration et sécurisation de SSH