Vérifier et renouveler en sécurité la clé SSH d’un Mac cloud

Lors de la première connexion à un Mac cloud, le terminal demande généralement s’il faut accepter un hôte inconnu. En utilisation manuelle, saisir yes est rapide ; dans un pipeline CI, définir StrictHostKeyChecking=no l’est encore davantage. Ces deux pratiques contournent toutefois la vérification d’identité. Une erreur de DNS, de configuration d’adresse ou de routage peut alors envoyer les identifiants et les artefacts de build vers la mauvaise machine. La bonne méthode consiste à récupérer d’abord l’empreinte de la clé d’hôte depuis un terminal de confiance, puis à configurer les postes de développement et les tâches automatisées pour qu’ils n’acceptent que cette clé.

Établir d’abord une référence de confiance indépendante

La clé d’hôte sert à prouver que la connexion aboutit bien au Mac attendu. Elle est distincte de la clé privée utilisée par l’utilisateur pour s’authentifier. Pour une clé d’hôte Ed25519, par exemple, ouvrez un terminal local sur la machine cible via le Web VNC de la console XcodeVM, puis relevez l’empreinte de la clé publique :

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

Conservez la valeur SHA256: complète, ainsi que l’identifiant de l’instance, l’adresse de connexion et la méthode utilisée pour relever l’empreinte. Ne récupérez pas cette valeur uniquement par la connexion SSH en cours de validation : la vérification reposerait alors sur elle-même.

Sur le poste de développement, récupérez ensuite la clé publique actuellement présentée par l’hôte distant :

mkdir -p ~/.ssh
chmod 700 ~/.ssh
ssh-keyscan -T 5 -t ed25519 "$MAC_HOST" > ~/.ssh/xcodevm_known_hosts.new
ssh-keygen -lf ~/.ssh/xcodevm_known_hosts.new -E sha256

Comparez les deux empreintes caractère par caractère. Si elles correspondent, installez le fichier :

install -m 600 ~/.ssh/xcodevm_known_hosts.new ~/.ssh/xcodevm_known_hosts
rm -f ~/.ssh/xcodevm_known_hosts.new

ssh-keyscan permet de récupérer une clé publique, mais ne prouve pas qu’elle est digne de confiance. Sans empreinte indépendante servant de référence, le résultat de l’analyse ne doit pas être ajouté directement au fichier de confiance utilisé en production.

Isoler known_hosts pour chaque projet

Le fichier global ~/.ssh/known_hosts convient aux connexions interactives courantes, mais un projet d’équipe devrait disposer de son propre fichier. Les changements deviennent ainsi explicitement vérifiables, et le nettoyage de l’historique personnel d’un développeur ne risque pas de perturber les tâches automatisées.

Créez un alias dans ~/.ssh/config :

Host xcodevm-build
    HostName 192.0.2.10
    User builder
    IdentityFile ~/.ssh/xcodevm_build_ed25519
    IdentitiesOnly yes
    UserKnownHostsFile ~/.ssh/xcodevm_known_hosts
    StrictHostKeyChecking yes
    HashKnownHosts yes
    ServerAliveInterval 30
    ServerAliveCountMax 3

L’option IdentitiesOnly yes évite que le client essaie successivement un trop grand nombre de fichiers d’identité. StrictHostKeyChecking yes impose quant à elle un échec immédiat si la clé est inconnue ou a changé. Avant de vous connecter, contrôlez la configuration effectivement appliquée afin de vérifier qu’aucune autre règle ne remplace les paramètres de l’alias :

ssh -G xcodevm-build |
  grep -E '^(hostname|user|identityfile|userknownhostsfile|stricthostkeychecking) '

Si un même projet utilise plusieurs machines, conservez une entrée distincte pour chacune et inscrivez l’identifiant de l’instance dans le journal interne des modifications. Évitez tout alias générique pointant vers une adresse susceptible de changer de manière imprévisible.

Épingler l’empreinte de la clé dans la CI

La CI ne doit pas dépendre en permanence du fichier de confiance personnel d’un développeur. Une approche plus robuste consiste à enregistrer l’empreinte SHA256 attendue dans une variable protégée, puis, à chaque tâche, à analyser et comparer la clé avant de créer un fichier known_hosts temporaire.

set -euo pipefail

: "${MAC_HOST:?MAC_HOST is required}"
: "${EXPECTED_ED25519_SHA256:?fingerprint is required}"

scan_file="$(mktemp)"
known_hosts_file="$(mktemp)"
trap 'rm -f "$scan_file" "$known_hosts_file"' EXIT

ssh-keyscan -T 5 -t ed25519 "$MAC_HOST" > "$scan_file" 2>/dev/null
actual="$(ssh-keygen -lf "$scan_file" -E sha256 | awk '{print $2}')"

if [ "$actual" != "$EXPECTED_ED25519_SHA256" ]; then
  printf '%s
' "SSH host key verification failed" >&2
  exit 1
fi

install -m 600 "$scan_file" "$known_hosts_file"

ssh \
  -o UserKnownHostsFile="$known_hosts_file" \
  -o StrictHostKeyChecking=yes \
  -o IdentitiesOnly=yes \
  "$MAC_USER@$MAC_HOST" \
  'uname -m && sw_vers -productVersion'

La clé privée, l’empreinte attendue et l’adresse de l’hôte doivent être gérées séparément. Les journaux peuvent afficher l’empreinte réellement obtenue pour faciliter le diagnostic, mais ils ne doivent jamais contenir la clé privée, le mot de passe de connexion ni des variables d’environnement non masquées.

Traiter correctement un changement de clé

Une clé d’hôte peut changer à la suite d’une réinitialisation du système, d’une régénération des clés ou de la réaffectation d’une adresse à une autre machine. Ce changement peut aussi indiquer que la connexion a été redirigée vers une cible incorrecte. Si le message REMOTE HOST IDENTIFICATION HAS CHANGED apparaît, commencez par interrompre les tâches automatisées. Il ne faut pas simplement supprimer l’ancienne entrée et réessayer.

Procédez au renouvellement sécurisé dans l’ordre suivant :

1. Dans la console, vérifiez l’identifiant de l’instance, l’adresse de connexion et la cohérence des opérations récentes.
2. Depuis le terminal local accessible par Web VNC, relevez de nouveau l’empreinte de la clé publique Ed25519.
3. Demandez à un autre responsable de contrôler les anciennes et nouvelles empreintes ainsi que le motif du changement.
4. Analysez la clé publique distante, vérifiez la nouvelle empreinte et générez un nouveau fichier de confiance.
5. Mettez d’abord à jour la tâche de test, puis effectuez une connexion en lecture seule et un contrôle de l’environnement.
6. Mettez ensuite à jour la tâche de production et révoquez l’ancienne empreinte.

Si les entrées sont hachées, commencez par localiser l’ancienne :

ssh-keygen -F "$MAC_HOST" -f ~/.ssh/xcodevm_known_hosts
ssh-keygen -R "$MAC_HOST" -f ~/.ssh/xcodevm_known_hosts

La deuxième commande ne doit être exécutée qu’après confirmation indépendante de la nouvelle empreinte. Supprimer l’ancienne entrée fait partie du renouvellement ; ce n’est pas une méthode de vérification.

Valider le déploiement avec une liste de contrôle

Avant la mise en production, vérifiez au minimum les points suivants :

Effectuez également un test négatif : remplacez temporairement l’empreinte attendue par une valeur incorrecte et vérifiez que la tâche s’arrête avant l’exécution effective de toute commande distante. Rétablissez ensuite la bonne valeur, puis testez une commande en lecture seule, l’accès au dépôt et le point d’entrée du build. Vous prouverez ainsi que la protection intervient réellement pendant l’exécution, au lieu d’être simplement présente dans un fichier de configuration.

Une chaîne de confiance SSH n’exige pas de système complexe. L’essentiel est de remplacer les validations improvisées lors de la première connexion ou après un changement de clé par une procédure vérifiable. Un terminal de confiance fournit la référence, un fichier propre au projet conserve l’association attendue, la CI la contrôle avant chaque connexion et tout changement entraîne d’abord un arrêt pour vérification. Une fois ces étapes appliquées, le développement à distance et les builds automatisés peuvent partager une même frontière d’identité d’hôte, claire et explicite.

Questions fréquentes