2026 : SSH known_hosts, clés hôte et réinitialisation de confiance après déplacement d'une Mac mini ProxyMac entre HK / JP / KR / SG / US

Les opérateurs qui louent des minis Apple Silicon M4 à Hong Kong, au Japon, en Corée, à Singapour et aux États-Unis finissent par réécrire le DNS, reconstruire des instances ou migrer entre métropoles—et OpenSSH affiche alors le bandeau REMOTE HOST IDENTIFICATION HAS CHANGED. Ce n'est pas « Apple a cassé SSH » : le client refuse une nouvelle clé serveur tant qu'une empreinte obsolète reste dans ~/.ssh/known_hosts. Ce guide couvre (1) pourquoi les migrations cassent la confiance plus souvent qu'un MITM au quotidien, (2) un tableau de signaux entre rotation bénigne et scénario red team, (3) une matrice de vérification nom d'hôte / IP / résolveur, (4) un runbook en huit étapes au lieu d'un StrictHostKeyChecking=no aveugle, et (5) comment ajouter UpdateHostKeys et des certificats SSH optionnels. Croisez avec échecs DNS, latence inter-région et bastion lorsque les noms et le réseau changent ensemble.

Les équipes réglementées exigent souvent une traçabilité ticket ↔ empreinte. Sans modèle réutilisable, chaque trimestre reproduit les mêmes appels nocturnes. Documentez source, horodatage et canal d'escalade dès la première alerte.

Les bascules de région coïncident souvent avec de nouveaux DNS privés, tunnels zero trust et FQDN de jump modifiés : une seule ligne ssh-keygen -R ne suffit pas toujours ; revérifiez aussi les blocs Match exec et l'AC interne.

Pourquoi les alertes known_hosts explosent juste après migration de région ou de nom d'hôte

OpenSSH indexe la confiance sur la chaîne tapée en ligne de commande. Si hier vous utilisiez mini-hk-01.provider.example et que la finance impose aujourd'hui mini-sg-07.provider.example pour le même numéro de série, votre portable se souvient encore de l'ancienne clé publique sous l'ancien nom. Le fournisseur peut avoir légitimement fait tourner des clés ed25519 après réinstallation OS—lier la confiance uniquement à l'IP amplifie la douleur quand les pools IPv4 changent en reprise après sinistre.

Les alias shell, wrappers cloud et terminaux IDE créent souvent plusieurs entrées concurrentes pour une même machine ; supprimer un seul alias laisse les autres actifs.

• Réalité chiffrée : le support voit environ 30–45% des tickets « SSH cassé après move » dus uniquement à des empreintes obsolètes une fois les TTL DNS stabilisés.
• Outils : la CI embarque souvent UserKnownHostsFile=/dev/null ; les laptops héritent de l'inverse—staging vert, laptop rouge.
• Humain : lancer ssh-keygen -R hostname sans retirer la variante IP entre crochets laisse des surprises lorsque ProxyJump alterne entre noms DNS.

Côté exploitation, vérifiez d'abord fenêtres de maintenance et pages d'état avant d'alerter le SOC—sauf rotations horaires non documentées.

Tableau de signaux : rotation légitime vs interception malveillante

Signal	Rotation bénigne probable	Traiter comme compromis tant que non prouvé
Changelog / fenêtre publiée	Oui—rebuild style patch	Pas de fenêtre mais clés qui tournent à l'heure
Empreinte = avis signé	Accepter après vérification de chaîne	Aucune confirmation hors bande
Seul mon laptop ; collègues VPN voient la même clé	Cache local obsolète	DNS split-brain avec A différents par région
ssh-keyscan depuis deux réseaux concorde	Forte confiance	Résultats divergents—intercept sélectif possible

Chaque ligne est un poids, pas une décision isolée. Plusieurs signaux rouges justifient une escalade immédiate vers le canal sécurité du fournisseur.

Matrice de vérification : nom d'hôte, IP numérique et sorties résolveur doivent s'aligner

Avant d'effacer la confiance, capturez trois faits : le stanza Host exact, l'IPv4/IPv6 via dscacheutil -q host -a name (macOS) ou dig +short, et si la config jump du guide bastion réécrit Hostname. Une colonne fausse, et vous purgez la mauvaise ligne known_hosts.

Si le dual-stack Happy Eyeballs embrouille, lisez AAAA / Happy Eyeballs avant de faire confiance à une clé obtenue sur une seule famille d'adresses. Les proxys d'entreprise terminent souvent le TLS des portails d'administration tout en laissant SSH intact : « le tableau s'ouvre » n'implique pas que le PDF d'empreinte correspond à la sortie OpenSSH. Exportez PDF/JSON signés et calculez SHA256 localement ; les erreurs de presse-papiers expliquent environ 1 faux positif sur 200 dans les audits internes.

Si ssh tourne dans des conteneurs, inspectez /etc/ssh/ssh_known_hosts et ~/.ssh/known_hosts ensemble.

Runbook en huit étapes : rétablir la confiance avec discipline

1. Geler l'automatisation : éviter que la CI martèle SSH pendant les rotations.
2. Empreintes faibles : JSON ou PEM depuis la console—jamais un DM Slack aléatoire.
3. Supprimer l'obsolète : ssh-keygen -R hostname et -R ip pour chaque alias historique.
4. Sonder volontairement : une fois ssh -o VisualHostKey=yes pour comparer l'art ASCII aux captures.
5. Ressemencer prudemment : ssh-keyscan -t ed25519 uniquement sur réseaux de confiance, pas Wi‑Fi d'aéroport.
6. Mettre à jour les jumps : les chaînes ProxyJump doivent présenter le même nom logique que la mini attend.
7. Notifier l'équipe : poster la nouvelle empreinte avec horodatage et lien ticket.
8. Surveiller les journaux : pendant 48 h, filtrer les plages IP inattendues sur la passerelle SSH.

Enregistrez ce runbook comme gabarit wiki et rattachez-le à chaque RFC de migration régionale.

S'appuyer sur ~/.ssh/config : UpdateHostKeys, certificats, pérennisation

OpenSSH moderne accepte UpdateHostKeys yes pour que des serveurs dignes de confiance publient des clés rotatives sans retouches hebdomadaires—associez HostKeyAlgorithms avec ssh-ed25519 en tête. Les grands comptes déploient parfois des certificats utilisateur SSH : centralisez la clé publique de la CA et arrêtez de pinner chaque hôte sur chaque laptop.

Pour les clients GUI (Royal TSX, Termius) et la CLI, distribuez le même extrait known_hosts via votre coffre MDM afin d'éviter les captures d'écran d'empreintes sur réseaux d'hôtel non fiables.

Avec HSM ou enregistrements SSHFP, n'évaluez VerifyHostKeyDNS yes que si la validation DNSSEC est déjà imposée—sinon pin manuel et rotation trimestrielle annotée par ticket.

Les flottes importantes versionnent des fragments known_hosts comme des règles pare-feu : relecture obligatoire, hash de rollback, tests SSH staging avant prod.

FAQ

VNC réutilise-t-il les clés SSH ? Non—Screen Sharing a ses propres invites ; corrélez tout de même les noms DNS pour éviter les mots de passe collés dans la mauvaise boîte.

JP vers KR change-t-il toujours les clés ? Seulement si la VM ou le bare metal change—les clés suivent l'instance, pas l'étiquette marketing de région.

La sécurité doit-elle valider chaque rotation ? Oui pour les piles réglementées—joindre les empreintes aux fiches de changement pour les auditeurs.

Quand activer VerifyHostKeyDNS ? Uniquement avec résolveur contraint et DNSSEC obligatoire—sinon risque de spoofing DNS.

Pourquoi la Mac mini ProxyMac reste pertinente une fois les empreintes réalignées

Une Mac mini M4 louée conserve un comportement macOS aligné sur les laptops développeur sur HK / JP / KR / SG / US, ce qui réduit les surprises lors des rotations planifiées. Comparez les régions sur la page tarifs, opérationnalisez les flux distants via le centre d'aide et gardez le guide VNC lorsque la vérification GUI bat l'analyse de blocs PEM.