MITM et confiance

SSH authentifie le serveur par sa clé d'hôte, à laquelle on fait confiance à la première utilisation et qui est épinglée dans known_hosts, ou signée par une CA pour le SSH basé sur les certificats. Lorsque cette confiance est faible, utilisateurs qui ignorent les avertissements de clé d'hôte, clients configurés pour accepter n'importe quelle clé, ou failles de validation de certificat, un attaquant bien positionné réalise un machine-in-the-middle pour capturer les identifiants et détourner la session.

1 min de lecturemis à jour le 13 oct. 2026florianamette1 contributeur
Demander à votre assistant (MCP)Modifier sur GitHub

SSH ne résiste au machine-in-the-middle que parce que le client vérifie la clé d'hôte du serveur : à la première connexion, la clé est enregistrée dans known_hosts (trust-on-first-use), et les connexions ultérieures doivent correspondre ou le client avertit. Le SSH basé sur les certificats remplace cela par une CA qui signe les clés d'hôte. La surface d'attaque est là où cette confiance est faible : utilisateurs conditionnés à accepter les avertissements de changement de clé d'hôte, clients configurés pour accepter n'importe quelle clé (StrictHostKeyChecking no), nouvelles connexions sans clé encore épinglée, et failles de validation de certificat. Un attaquant bien positionné les exploite pour s'interposer, présentant sa propre clé d'hôte, déchiffrant la session, capturant le mot de passe ou la clé, et relayant vers le vrai serveur.

bash
# position (ARP/DNS/route) + an SSH MITM proxy that presents a substitute host key
# the attack succeeds when the client does not reject the unknown/changed key

Sous-thèmes#

Références#

PrécédentÉnumération d'utilisateursSuivant Contournement de validation de certificat