Summary

  • Le RFC 4251 décrit un carnet local qui associe un nom d’hôte à sa clé publique : une clé acceptée lors d’une première visite devient la référence des visites suivantes.
  • OpenSSH conserve cette référence dans known_hosts. Ses réglages distinguent une clé inconnue d’une clé modifiée, et un serveur déjà authentifié peut annoncer ses futures clés avant d’abandonner l’ancienne.

Un serveur SSH possède une clé d’hôte. Lors de l’échange cryptographique, le client doit relier cette clé à la machine qu’il voulait joindre. Le RFC 4251, publié en janvier 2006, propose deux architectures : un registre local des associations entre noms et clés, ou une autorité de certification de confiance. Le registre local évite de demander la permission à un bureau central. Il oblige en revanche à soigner la première poignée de main.

Le document décrit une méthode particulièrement humaine : accepter la clé rencontrée une première fois, la ranger, puis la comparer à chaque nouvelle visite. La protection naît de la mémoire. Si quelqu’un intercepte la première rencontre, il peut faire enregistrer sa propre clé. C’est pourquoi le RFC évoque la vérification d’une empreinte par un autre moyen de communication. Une fois la véritable clé consignée, un nouvel arrivant ne peut plus simplement emprunter le même nom et compter sur l’amnésie du client.

Dans OpenSSH, le carnet a un nom peu romanesque : ~/.ssh/known_hosts. Le manuel ssh(1) d’OpenBSD décrit son rôle et l’avertissement spectaculaire qui accompagne un changement de clé connu. L’alerte ne prétend pas identifier le coupable. Un administrateur a pu reconstruire le serveur ou remplacer sa clé ; un intrus peut aussi présenter la sienne. Elle constate une rupture dans l’histoire enregistrée et interrompt la conversation.

Le manuel ssh_config(5) donne plusieurs tempéraments à ce gardien. StrictHostKeyChecking=ask interroge l’utilisateur sur une nouvelle clé et refuse celle qui remplace une clé connue. accept-new note les nouveaux venus sans poser la question, puis refuse également les changements. yes exige l’installation préalable de toute nouvelle clé. Les réglages accélèrent ou ralentissent l’accueil ; ils conservent la distinction décisive entre « inconnu » et « différent de mon souvenir ».

Un changement légitime peut se préparer. Avec UpdateHostKeys, le serveur déjà authentifié communique d’autres clés au client. Celui-ci apprend la future clé tant que l’ancienne prouve encore l’identité du serveur. Le passage de témoin vaut mieux qu’un inconnu sur le pas de la porte disant : « C’est moi, j’ai changé de coiffure. »

On peut remplir le carnet rapidement avec ssh-keyscan. Son propre manuel rappelle que la collecte ne vérifie pas l’authenticité des clés : un acteur placé sur le réseau peut fournir les siennes. La rapidité d’une copie ne garantit jamais la qualité de la première présentation. La grande idée est plus modeste et plus durable : faire répondre les rencontres futures de ce qui fut noté hier.