Points de friction : un upload peut réussir vers la mauvaise machine
Friction 1 : confondre authentification et identification. Clés utilisateur, jetons OIDC et deploy keys répondent « ce client peut-il se connecter ? ». Les clés hôte répondent « ce serveur est-il bien celui visé ? ». Des journaux de transfert ne révèlent pas un intermédiaire si la vérification hôte est absente ou réinitialisée à chaque run.
Friction 2 : confiance au premier regard à chaque job. Les runners hébergés par GitHub sont souvent jetables. Scanner la clé au début du workflow, c’est accepter le premier résultat vu depuis ce réseau-là, nettement plus faible qu’un poste fixe dans un LAN contrôlé.
Friction 3 : explosion d’alias sans tableau d’empreintes. Prod sur DNS, staging sur IP privée, CI via bastion : sans matrice écrite, un CNAME ou un load balancer fait tourner les clés silencieusement pendant que les pipelines restent verts sous politique laxiste.
Friction 4 : mélanger AC utilisateur et politique hôte. Une autorité de certification SSH côté utilisateurs ne supprime pas la validation des clés hôte. Ignorer l’hôte tout en durcissant les utilisateurs crée un déséquilibre que les audits remarquent vite.
Friction 5 : la concurrence masque les causes. Quand plusieurs jobs frappent la même entrée réseau du Mac distant, erreurs MITM ou mismatch se mélangent aux limites de sessions. Sans compteurs séparés, l’astreinte poursuit du bruit.
Friction 6 : questionnaires de sécurité en retard. On parle signatures d’artefacts et SLSA, pas assez SSH hôte. Découvrir StrictHostKeyChecking=no dans un workflow réutilisable force un bricolage sous pression. Anticipez fragments et tickets de rotation.
Friction 7 : egress multi-région ambigu. Avec proxys ou sorties régionales, le comportement SSH peut diverger sans changer le Mac. L’épinglage rend les divergences visibles au lieu d’accepter des clés différentes par région.
Dans les équipes françaises, la conformité (traçabilité, droit à l’audit) pousse à documenter qui a validé quelle empreinte. Sans lien entre Secret, ticket Jira et fiche réseau, on se retrouve avec des workflows verts mais une chaîne de preuve incomplète lors d’un contrôle. Épingler n’est pas une option « crypto Twitter » : c’est aligner l’identité réseau avec la gouvernance des releases. Les artefacts iOS/macOS contiennent souvent des morceaux sensibles : provisioning, entitlements, symboles. Le canal de publication mérite la même rigueur qu’un endpoint API OAuth.
Les équipes SRE oublient parfois que les développeurs copient des snippets Stack Overflow contenant ssh-keyscan github.com mélangé à vos hôtes internes. Un grep CI qui interdit le motif sans contexte crée des faux positifs ; un grep trop laxiste laisse passer des trous. La bonne approche est une allowlist de fichiers ou de commentaires explicites, combinée à une revue obligatoire pour toute exception temporaire.
Modèle de menace : les clés hôte sont du change management
Les binaires et bundles livrés en CI portent souvent des informations exploitables même si le dépôt est public. Traiter le tunnel SSH comme canal sensible est raisonnable. La vérification des clés hôte est l’un des rares mécanismes qui attache la session à du matériel de clé précis, pas seulement au DNS.
StrictHostKeyChecking=accept-new aide sur poste interactif car il refuse les changements après premier enregistrement. Sur runner vierge, « nouveau » revient à chaque démarrage si vous n’injectez pas de lignes : retour au TOFU.
UserKnownHostsFile sépare la confiance CI du fichier personnel souvent pollué par des tests Wi-Fi ou des bastions improvisés. Pour un audit, le fragment Secret se rattache à une approbation sans aspirer les laptops.
Les topologies bastion exigent une feuille par saut. Épingler la cible sans épingler le jump expose encore le scénario bastion compromis. Alignez la doc sur le guide ProxyJump pour un runbook unique réseau/plateforme.
Après la mutation scp→SFTP, séparez erreurs d’identité hôte et erreurs sémantiques de chemins ou globs pour ne pas réparer la mauvaise couche.
En 2026, la chaîne d’approvisionnement logicielle valorise la reproductibilité. Une ligne known_hosts figée se traite comme un artefact versionné : revue, propriétaire, rollback. Les noms de Secrets font partie de l’API interne de la plateforme.
Les exercices de reprise doivent inclure une rotation volontaire de clé hôte. Si vous ne touchez known_hosts qu’en incident, les erreurs s’accumulent. Un drill trimestriel sur staging met l’équipe en confiance.
Choisissez une convention hashes vs noms en clair ; mélanger les styles rend les diffs illisibles et complique les revues croisées entre sécurité et développement.
Pensez aux vues DNS internes et externes : le même nom peut résoudre différemment depuis GitHub et depuis le bureau. Votre matrice doit nommer explicitement quelle vue alimente quel Secret, sinon les « ça marche chez moi » deviennent des incidents de production.
Les équipes conformes RGPD ne traitent pas forcément les clés hôte comme données personnelles, mais les journaux qui capturent des échecs SSH peuvent contenir des identifiants de comptes techniques. Anonymisez ou tronquez ce qui n’est pas nécessaire tout en gardant assez de contexte pour prouver que l’épinglage a fonctionné comme prévu.
Baselines mesurables pour arrêter de dire que « SSH est capricieux »
Journalisez ssh -V côté runner et Mac distant à chaque bump d’image ou de macOS. Affichez le chemin effectif de UserKnownHostsFile et l’alias utilisé par rsync, sans fuite de clés privées. Deux lignes de log valent des heures de comparaison de jobs.
Scindez les métriques : échecs de vérification hôte, permission denied, disque plein. Un agrégat « erreur upload » noie le signal. Avec OIDC, traitez politique hôte et politique jeton dans le même changement — voir la matrice OIDC.
Liez toute rotation de clé hôte à un événement de cycle de vie machine et à une barrière de contrôle d’intégrité issue de l’article checksums. Une courte fenêtre à deux lignes évite une panne globale des workflows.
Provoquez des sondes depuis plusieurs régions si l’egress diffère. Des empreintes divergentes pointent vers split-horizon ou proxy captif plutôt que vers une panne du Mac.
Ajoutez un lint qui échoue sur StrictHostKeyChecking=no ou ssh-keyscan non commenté. Ce garde-fou stoppe les régressions triviales.
Corrélez incidents hôte et journaux CT pour vos domaines builder quand c’est pertinent : un renommage DNS surprise précède parfois une rotation mal synchronisée.
Quand vous publiez un manifeste SHA256, référencez sur le même ticket le chemin du manifeste et l’alias SSH utilisé : les auditeurs aiment lier identité réseau et identité des octets.
La vérification hôte coûte négligeable face à chiffrement et disque ; ne sacrifiez pas la sécurité pour des microsecondes imaginaires.
Ajoutez la résolution DNS et l’empreinte attendue (tronquée) dans les messages d’erreur enrichis côté workflow : quand un proxy TLS inspecte autre chose que prévu, l’équipe réseau comprend vite sans partager de secrets.
Documentez aussi les algorithmes de signature hostkey acceptés par votre sshd sur Mac distant : un runner récent peut refuser des types anciens et produire des messages qui ressemblent à un mismatch d’épinglage alors que c’est une négociation crypto.
Matrice StrictHostKeyChecking pour la CI
| Politique | Mieux pour | Bénéfice | Risque |
|---|---|---|---|
StrictHostKeyChecking=no | Rien en prod | Friction faible | MITM ; audit impossible |
ssh-keyscan inline | Prototypes | Rapide à écrire | TOFU à chaque run |
accept-new sans lignes injectées | Labos peu sensibles | Bloque clés modifiées après premier vu | Premier vu dangereux sur disque vide |
Lignes épinglées + UserKnownHostsFile + yes | Prod, flotte Mac | Auditable, rotatif | Hygiène des Secrets |
| Attestation hôte managée | Grands parcs cloud | Automatisation | Dépend du fournisseur |
Croisez avec staging de publication atomique pour ne jamais mélanger réseau « tout accepter » et chemins de prod.
Étapes opérationnelles : des Secrets à rsync vérifié
# Collect keys offline from a trusted admin host, not inside CI
# ssh-keyscan -p 22 -H remote-mac.example.com > ci_known_hosts.fragment
# ssh-keygen -lf ci_known_hosts.fragment
# Store fragment in GitHub Secret SSH_KNOWN_HOSTS (host keys only)
# mkdir -p ~/.ssh && chmod 700 ~/.ssh
# printf '%s\n' "${{ secrets.SSH_KNOWN_HOSTS }}" > ~/.ssh/ci_known_hosts
# chmod 644 ~/.ssh/ci_known_hosts
# export RSYNC_RSH='ssh -o BatchMode=yes -o StrictHostKeyChecking=yes -o UserKnownHostsFile=$HOME/.ssh/ci_known_hosts'
# Append bastion lines when using ProxyJump; verify ordering matches ~/.ssh/config Host blocks
# rsync -av ./dist/ user@remote-mac:/Volumes/builds/app/dist/
# ssh user@remote-mac 'shasum -a 256 -c manifest.sha256'
Encapsulez les options dans une action composite pour éviter la dérive des copier-coller entre dépôts.
Ordre de lecture et alignement CTA
Lisez d’abord cet article, puis OIDC, certificats utilisateur, sémantique scp/SFTP, checksums, publications atomiques, et la page d’accueil pour l’offre.
Réordonner crée de faux dilemmes : certs utilisateur parfaits avec confiance hôte molle, ou pins parfaits avec scripts scp cassés. Partagez une table d’approbation unique : alias, empreintes, Secrets, owners, budgets de concurrence.
Faire du Mac distant la source de vérité de build limite la pollution de confiance des laptops. L’édition reste locale ; compilation, signature et upload se font sur un nœud Apple stable — cohérent avec un ingress épinglé.
Les actions composites améliorent l’expérience développeur en nommant remote_alias et known_hosts_secret plutôt qu’une ribambelle d’options OpenSSH.
Formez avec une démo live : écrire le fragment, interpréter ssh-keygen -lf, montrer une coupure MITM en labo. Les équipes adoptent plus vite quand elles voient l’échec attendu.
Alignez la doc sur les heures de garde promises. Sans fenêtres de maintenance claires, les rotations deviennent des surprises pour l’astreinte.
Si plusieurs produits partagent un builder, centralisez le Secret au niveau organisation et ne dupliquez pas des empreintes légèrement différentes par équipe : c’est la voie rapide vers des audits contradictoires.
Enfin, tracez dans votre SIEM le taux d’échecs par type d’erreur OpenSSH ; une bosse sur « host key verification failed » doit déclencher une revue réseau avant de pointer du doigt le Mac distant.
FAQ et quand un Mac distant hébergé SFTPMAC aide
Les clés publiques d’hôte sont-elles secrètes ?
Non, mais les Secrets réduisent les modifications opportunistes dans les YAML et cadrent les processus de changement. Ne mélangez pas de clé privée utilisateur dans le même secret.
arm64 vs x64 côté runner ?
Les pins suivent la cible distante, pas l’architecture du runner. La cohérence DNS sur les chemins de sortie reste critique.
Jump host et appli partagent-ils le même Secret ?
Mieux vaut des noms distincts ou un format structuré nettoyé avant écriture pour éviter les mises à jour partielles.
Runners self-hosted sur VM longue durée ?
Isoler via UserKnownHostsFile reste utile : le disque accumule des entrées de test. Harmonisez la politique avec les runners jetables.
Résumé : la vérification des clés hôte est une configuration CI de premier plan, pas une habitude personnelle recopiée.
Limites : opérer soi-même une flotte Mac distant exige patchs, stockage, astreinte et rotation disciplinée des Secrets. Pour un ingress SFTP/rsync prévisible sur Apple Silicon sans monter toute cette plateforme, SFTPMAC regroupe disponibilité, isolation de répertoires et playbooks afin de livrer des binaires plutôt que de rejouer des scénarios MITM à chaque rafraîchissement de runner.
Épinglez clés hôte, bastions et outils d’upload dans un seul runbook ; les environnements hébergés rendent les rotations auditables entre équipes.