Pourquoi la rotation des clés de déploiement ne suffit pas
Friction 1 : deux chaînes, un ticket. L'authentification utilisateur et l'identité serveur sont distinctes en SSH. Après réinstallation macOS, si vous ne faites tourner que la clé GitHub, vous verrez WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED — ce n'est pas un défaut de l'épinglage, c'est l'absence de runbook host key.
Friction 2 : big-bang à minuit. Nouvelle clé Ed25519, RSA retirée immédiatement, Secret mis à jour sans chevauchement : cinquante workflows échouent d'un coup. L'architecture était bonne, la discipline de release non.
Friction 3 : UpdateHostKeys mal compris. UpdateHostKeys yes aide les postes interactifs. La CI avec StrictHostKeyChecking=yes et UserKnownHostsFile statique exige deux lignes dans le Secret pendant la fenêtre — pas de magie automatique.
Friction 4 : ControlMaster masque le timing. Les sessions multiplexées peuvent garder un ancien contexte. Consultez la matrice ControlMaster et purgez ControlPath pendant la rotation.
Friction 5 : l'OIDC ne remplace pas l'empreinte. Les jetons de pipelines OIDC authentifient le client, pas que la machine jointe est votre builder.
En production française ou belge, documentez la rotation dans le registre des traitements si des journaux SSH contiennent des métadonnées de connexion liées à des environnements de test avec données personnelles — minimisation et durées de conservation selon le RGPD.
Avant toute rotation : ssh-keygen -lf sur chaque ssh_host_*_key.pub et alignement avec le registre d'épinglage du guide known_hosts.
Friction 6 : erreurs sémantiques après le fix host key. Une fois la connexion rétablie, les jobs échouent sur des globs ou droits. Séparez les runbooks : identité réseau d'abord, sémantique d'upload ensuite.
Friction 7 : conformité sans réalité ops. Les audits demandent « rotation de clés » mais seulement côté utilisateur. Ajoutez une ligne explicite pour les empreintes host key et la preuve du chevauchement.
Matrice : double clé, sur place ou coupure nette
Double clé avec chevauchement (recommandé). Le serveur offre RSA et Ed25519 ; le Secret CI contient les deux lignes ; retrait legacy après canary.
Sur place côté serveur seulement. Un seul fichier clé, nouveau type, UpdateHostKeys pour les laptops — la CI doit quand même mettre à jour le Secret.
Coupure nette en fenêtre de maintenance. Acceptable pour un seul consommateur ; risqué pour des dizaines de dépôts.
Nouveau nom d'hôte. builder-v2.internal avec épinglage frais et bascule DNS — évite des empreintes mixtes sur un même nom.
La matrice doit lister propriétaire, nom de Secret, fin de chevauchement et rollback (clés publiques archivées).
Évaluez les sauts bastion : rotation coordonnée du jump et de la cible, sinon des erreurs « SSH flaky » intermittentes.
Étendez la matrice par environnement : staging canary vert ne justifie pas la prod sans second canary.
Anticipez la dépréciation RSA host key : planifiez un chevauchement plus long que 24 h si des outils legacy restent sur le terrain.
Côté serveur sur le Mac distant : Ed25519 et sshd
Sous macOS, les clés hôte sont dans /etc/ssh/ssh_host_*. Générez Ed25519 avec ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N "" sur la console admin — jamais dans la CI.
Ajoutez HostKey /etc/ssh/ssh_host_ed25519_key dans sshd_config ou sshd_config.d/ ; gardez RSA/ECDSA le temps du chevauchement. Validez avec sudo sshd -t puis rechargement contrôlé — pas de restart aveugle en plein upload.
Les clients modernes négocient Ed25519 ; les anciens retombent sur RSA tant que le serveur propose les deux. Journalisez le type négocié via ssh -vvv dans le ticket.
Retirez les lignes HostKey legacy seulement après canary vert et Secret à une seule ligne Ed25519. Archivez les .pub en lecture seule.
Vérifiez que la MDM ne réécrase pas vos fragments sshd_config.d au prochain sync.
Si sshd écoute sur une IP Tailscale ou interne, ssh-keyscan doit utiliser le même chemin réseau que la CI — attention au split DNS.
Test forcé : ssh -o HostKeyAlgorithms=ssh-ed25519 puis test sans contrainte pour le fallback.
Clients et CI : UpdateHostKeys et chevauchement des Secrets
Sur les laptops : bloc Host builder-* avec UpdateHostKeys yes et politique StrictHostKeyChecking explicite.
En CI : StrictHostKeyChecking=yes, UserKnownHostsFile dédié, Secret à deux lignes pendant le chevauchement — détails dans le guide d'épinglage.
HashKnownHosts protège la vie privée des captures ; gardez une table de correspondance interne pour les audits.
Versionnez les noms de Secret (SSH_KNOWN_HOSTS_2026_05) jusqu'au canary vert ; exportez RSYNC_RSH via une action composite.
Terminez les sessions ControlMaster obsolètes — voir l'article keepalive. Limitez la parallélité en test pour distinguer host key vs MaxSessions.
Les forks sans Secrets hérités cassent seulement une partie des pipelines — communiquez via les canaux plateforme.
SFTP batch et rsync partagent la même couche host key : incluez les deux dans le même canary.
Interdisez StrictHostKeyChecking=no même « pour une nuit » sur la branche par défaut.
Qui met à jour quoi ?
| Couche | Outil | Chevauchement | Erreur typique |
|---|---|---|---|
| sshd | plusieurs HostKey | oui | RSA retiré trop tôt |
| Poste dev | UpdateHostKeys yes | après handshake | StrictHostKeyChecking=no |
| GitHub Actions | Secret 2 lignes | manuel daté | nouvelle ligne seule |
| OIDC | inchangé | — | jeton remplace host key |
Extrait de runbook
# Console admin Mac distant (pas CI)
# sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
# sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
# HostKey dans sshd_config.d ; garder l'ancien HostKey jusqu'à fin du chevauchement
# sudo sshd -t && rechargement sshd contrôlé
# Hors ligne : ssh-keyscan pour Secret (deux lignes pendant le chevauchement)
# Client : UpdateHostKeys yes ; CI : StrictHostKeyChecking=yes + UserKnownHostsFile
# Canary : ssh -o BatchMode=yes -o UserKnownHostsFile=$HOME/.ssh/ci_known_hosts host trueFixez OVERLAP_END dans le ticket ; retirez la ligne legacy après canary.
Lorsque OpenSSH déprécie les host keys RSA faibles, la migration Ed25519 n'est pas qu'une mode : c'est la préparation aux clients qui refuseront de négocier d'anciens types. Gardez RSA en parallèle le temps que tous les consommateurs — humains et CI — aient validé le canary Ed25519.
Les équipes qui mélangent SFTP graphique et rsync en CI doivent tester les deux chemins après chaque changement de HostKey : le même sshd sert les deux, mais les clients peuvent mettre en cache des sessions différemment.
Si votre bastion et votre Mac builder partagent une équipe réseau, incluez-les dans le même change advisory : une rotation partielle produit des erreurs qui ressemblent à de l'instabilité réseau.
Pour les organisations multi-cloud, un registre host key central évite que chaque région maintienne un Secret légèrement différent après un ssh-keyscan local non vérifié.
En résumé opérationnel : générer, valider sshd -t, chevaucher Secret et HostKey, canary, communiquer OVERLAP_END, retirer legacy — dans cet ordre, sans exception « temporaire » sur StrictHostKeyChecking.
Pratique supplémentaire : ajoutez à la Definition of Done du ticket infra « Secret et sshd_config à jour, canary vert, legacy retiré » avant de lancer le déploiement applicatif.
Runners macOS et Linux vers le même Mac distant partagent le même pinning host key — seule la couche transport change.
Pratique supplémentaire : ajoutez à la Definition of Done du ticket infra « Secret et sshd_config à jour, canary vert, legacy retiré » avant de lancer le déploiement applicatif.
Runners macOS et Linux vers le même Mac distant partagent le même pinning host key — seule la couche transport change.
Pratique supplémentaire : ajoutez à la Definition of Done du ticket infra « Secret et sshd_config à jour, canary vert, legacy retiré » avant de lancer le déploiement applicatif.
Runners macOS et Linux vers le même Mac distant partagent le même pinning host key — seule la couche transport change.
Pratique supplémentaire : ajoutez à la Definition of Done du ticket infra « Secret et sshd_config à jour, canary vert, legacy retiré » avant de lancer le déploiement applicatif.
Runners macOS et Linux vers le même Mac distant partagent le même pinning host key — seule la couche transport change.
Vérification, ordre de lecture et rollback
Workflow workflow_dispatch : ssh -o BatchMode=yes et petit rsync --dry-run avant de retirer l'ancienne ligne HostKey.
Métriques séparées : Host key verification failed vs Permission denied vs disque plein.
Rollback : réactiver l'ancienne ligne HostKey, restaurer le Secret, sshd -t, clés pub archivées.
Ordre de lecture : known_hosts, ce guide rotation, ControlMaster, OIDC.
Annoncez la fin du chevauchement à tous les propriétaires de dépôts utilisant les Org Secrets.
Drill trimestriel sur staging avec rollback ; mesurez le délai de mise à jour des Secrets.
Canary par région d'egress si vous avez plusieurs zones runner.
Une action composite avec known_hosts_secret réduit l'improvisation à chaque rotation.
Les équipes plateforme gagnent à traiter chaque ligne host key comme un artefact versionné : revue, propriétaire, date de fin de chevauchement — au même titre qu'un lockfile d'infrastructure.
Lors d'un restore Time Machine ou clone disque, vérifiez que les fichiers sous /etc/ssh/ n'ont pas été ramenés à un état antérieur ; sinon la CI verra un troisième empreinte inattendue.
En cas d'urgence : ne désactivez pas StrictHostKeyChecking — élargissez HostKey côté serveur et Secret côté CI, canary, puis retirez le legacy.
Les runbooks d'incident doivent distinguer « empreinte host key refusée » et « permission refusée après authentification ». Sans cette séparation, on réattribue les échecs rsync à des droits SFTP alors que le tunnel n'a jamais atteint le bon serveur.
Pour les pipelines signant des binaires iOS ou macOS, le canal d'upload est aussi sensible que le magasin de secrets : une rotation host key planifiée vaut mieux qu'un correctif d'urgence un vendredi soir avec StrictHostKeyChecking=no temporaire.
Les fournisseurs Mac hébergés annoncent parfois des fenêtres de maintenance alignées sur le remplacement matériel : alignez vos Secrets GitHub sur le même calendrier et testez un canary la veille.
Si plusieurs dépôts consomment un Org Secret, une seule table de rotation partagée évite que chaque équipe maintienne une variante légèrement différente de ssh-keyscan.
Documentez le port, l'alias DNS et l'algorithme négocié dans le ticket — les auditeurs comparent souvent le PDF de politique aux valeurs réelles observées en CI.
Les runners auto-hébergés sur VM longue durée bénéficient aussi d'un UserKnownHostsFile isolé : le disque accumule des entrées de test qui polluent le pinning de production.
Après retrait de la ligne RSA legacy côté sshd, gardez une copie archivée du .pub pendant au moins un cycle de release pour rollback forensique.
Enfin, reliez la rotation host key aux barrières SHA256 sur les artefacts : un seul ticket peut lier identité réseau et identité des octets livrés.
Les équipes françaises soumises au RGPD peuvent limiter les journaux SSH aux métadonnées strictement nécessaires (horodatage, résultat, empreinte tronquée) et éviter de coller des extraits de known_hosts complets dans des tickets publics.
Un lint de workflow qui bloque StrictHostKeyChecking=no protège la rotation : la pression « pour débloquer la nuit » ne doit pas devenir la norme sur main.
Pensez au chevauchement comme à une fenêtre de compatibilité API : les clients anciens et la CI strict coexistent jusqu'à la date de fin documentée.
Les erreurs « REMOTE HOST IDENTIFICATION HAS CHANGED » sur les postes développeurs sont un signal d'alignement, pas une invitation à supprimer ~/.ssh/known_hosts en bloc sans ticket.
FAQ et Mac distant hébergé
Un registre central « host key » à côté de la CMDB — alias, port, type, SHA256, Secret, fin de chevauchement — évite les copier-coller wiki obsolètes.
Ed25519 est-il obligatoire ?
Recommandé pour les nouvelles clés hôte ; RSA peut rester pendant le chevauchement.
UpdateHostKeys modifie-t-il mon Secret CI ?
Non — la CI à épinglage strict nécessite des lignes manuelles.
Que journaliser ?
Empreintes tronquées, ticket, fin de chevauchement — pas de clés privées utilisateur ; durées RGPD sur les journaux SSH.
Quand SFTPMAC aide ?
Pour des fenêtres de maintenance annoncées et des runbooks d'ingress sans gérer vous-même toute la flotte.
En bref : rotation planifiée côté serveur et client — Ed25519 sur le Mac, chevauchement dans les Secrets, UpdateHostKeys pour les humains, épinglage strict pour la CI.
Chevauchement plutôt que big-bang ; les Mac hébergés SFTPMAC peuvent regrouper les annonces d'empreintes.