Résumé

  • Une correspondance SSHFP authentifiée par DNSSEC peut relier l’algorithme et l’empreinte d’une clé d’hôte SSH à un nom DNS précis. Elle ne prouve pas que ce nom était la destination voulue et ne transporte ni port, ni utilisateur, ni commande.
  • La décision complète compose la sélection du nom, l’état DNSSEC, la comparaison exacte de la clé, la preuve de possession SSH et la politique locale. Une rotation ajoute les horloges des caches DNS et des fichiers de clés connus.

Une preuve exacte sur le mauvais sujet

Dans l’exemple, aucun attaquant n’a falsifié de signature. Le résolveur a construit un nom complet, la chaîne DNSSEC a validé le RRset SSHFP, et le serveur a prouvé qu’il détenait la clé privée correspondant à l’empreinte publiée.

La question manquante se trouve en amont : qui a décidé que cette expansion de db désignait le bon service ?

RFC 4255 traite précisément le cas des noms non qualifiés. Il recommande de vérifier d’abord une base locale, car un chemin de recherche injecté peut conduire le client vers un autre hôte. Un DNS sécurisé peut donc répondre correctement à une question mal formée. Il protège l’intégrité de la réponse ; il ne restaure pas l’intention de l’utilisateur.

Le journal doit conserver le nom saisi, le nom canonique effectif, la règle CNAME ou le suffixe appliqué, le propriétaire SSHFP interrogé, l’adresse et le port. Une seule colonne « host » efface le transfert d’autorité décisif.

Ce que contient réellement SSHFP

SSHFP est le type DNS 44. Le RDATA contient un numéro d’algorithme de clé publique, un type d’empreinte et les octets de cette empreinte. Le nom propriétaire appartient au RR, hors du RDATA.

Une correspondance exige deux égalités. L’algorithme de la clé reçue doit être celui indiqué par le record. Le condensat du blob de clé, calculé avec l’algorithme d’empreinte annoncé, doit être identique à la valeur publiée.

Cette opération ne remplace pas l’échange SSH. Le serveur signe encore les données de l’échange avec sa clé d’hôte. Il démontre ainsi la possession de la clé privée pour cette session. Il ne démontre pas que cette copie est unique : une clé volée ou clonée produit la même preuve valide.

Le format révèle aussi sa limite. Il ne contient ni port TCP, ni nom d’utilisateur, ni commande, ni rôle métier, ni adresse IP, ni date d’expiration. Associer une clé à host.example ne décide pas si le service visé écoute sur le port 22, sur un port secondaire ou derrière un bastion.

Secure est un état de validation

RFC 4255 interdit de faire confiance à la clé par cette méthode si le SSHFP utilisé n’a pas été authentifié par une signature DNS de confiance. Un client peut valider lui-même. S’il délègue la validation, le transport vers le validateur doit être protégé ; un indicateur reçu sur un chemin falsifiable ne suffit pas.

Les états doivent rester distincts. Secure signifie que les données pertinentes se valident sous une ancre acceptée. Insecure signifie que la chaîne établit l’absence de protection. Bogus signale un échec alors qu’une validation était attendue. Indeterminate indique que les informations de confiance ne permettent pas de conclure.

Une empreinte identique sous Insecure est un renseignement, pas l’autorité automatique requise par le standard. Bogus ne doit pas devenir Insecure pour préserver la disponibilité. Indeterminate doit nommer l’ancre ou le lien manquant.

Même Secure ne choisit pas le nom. Il atteste le RRset sous le propriétaire interrogé. Un suffixe DHCP ou une règle de canonicalisation peut être authentique et néanmoins inadéquat pour la tâche.

Le repli de condensat est une décision de sécurité

Le registre IANA actuel attribue des numéros à RSA, DSA, ECDSA, Ed25519 et Ed448 ; les types d’empreinte enregistrés sont SHA-1 et SHA-256. Un numéro décrit l’encodage interopérable, pas le support réel d’un client.

RFC 6594 impose une règle négative importante. Un client compatible SHA-256 doit le préférer quand SHA-1 et SHA-256 coexistent. Si le SHA-256 testé ne correspond pas, il faut rejeter la clé au lieu de chercher une approbation de secours dans un record SHA-1 correspondant.

La télémétrie doit donc conserver chaque tuple testé : nom propriétaire, algorithme de clé, type d’empreinte, valeur calculée et résultat. Le résumé sshfp=match ne révèle ni un échec plus fort ni un repli abusif.

La politique locale tranche encore

RFC 4255 laisse les implémentations ordonner SSHFP, fichiers locaux et autres méthodes. La documentation OpenSSH actuelle rend le choix concret. VerifyHostKeyDNS vaut no par défaut. Avec yes, une clé correspondant à une empreinte DNS sécurisée est implicitement approuvée ; une empreinte non sécurisée est traitée comme ask. Avec ask, l’information s’affiche mais une nouvelle clé suit encore StrictHostKeyChecking.

Les bases globales et utilisateur, les blocs Host et Match, la canonicalisation, les CNAME autorisés et l’ordre de première valeur complètent le graphe. Il faut enregistrer la configuration effective au moment de la connexion, pas seulement le fichier qu’un administrateur pensait actif.

Un conflit entre une ancienne clé locale et un nouveau SSHFP Secure est justement un conflit de politiques. Le masquer derrière un badge vert supprime un veto dont l’organisation peut avoir besoin.

Le port et le chemin ne sont pas dans le record

OpenSSH sait retirer de known_hosts une identité qualifiée sous la forme [hostname]:port, tandis que ssh-keygen -r génère un SSHFP nommé par un hostname. Cette différence d’interface reflète le format : une base locale peut distinguer un port, SSHFP ne le transporte pas.

Ce n’est pas une défaillance du protocole. C’est son unité d’autorité. Si deux démons SSH sous un même nom présentent des clés différentes, la politique applicative doit définir le modèle. Le RR ne choisit pas à sa place.

Un ProxyJump ajoute une autre clé et un autre propriétaire. Authentifier la destination finale ne rend pas le bastion authentique par transit. Chaque liaison matérielle exige sa propre décision de clé d’hôte.

Une rotation possède deux horloges

RFC 4255 envisage le remplacement du SSHFP pour distribuer une nouvelle clé et, si la politique exige SSHFP, sa suppression comme élément de révocation. Ces effets dépendent du client réellement exécuté.

Les anciennes réponses restent dans les caches jusqu’au TTL ; les RRSIG ont leur propre période. Les clients possèdent aussi des pins locaux. Présenter la nouvelle clé avant la propagation du nouveau RR provoque un refus légitime. Supprimer l’ancien RR sur l’autorité ne prouve pas sa disparition de tous les caches.

Une rotation maîtrisée prépublie la nouvelle empreinte par un canal d’inscription authentifié, l’observe depuis des validateurs significatifs, maintient un chevauchement borné, change la clé servie, retire l’ancienne association puis teste son refus après expiration. Une urgence peut sacrifier la disponibilité, mais cette décision doit être nommée.

Vérifier le serveur n’autorise pas l’utilisateur

L’architecture SSH sépare l’authentification du serveur au niveau transport et l’authentification de l’utilisateur. Une clé d’hôte acceptée protège un canal vers le serveur sélectionné. Elle n’accepte pas une identité cliente, un shell, un transfert de port ou une commande privilégiée.

L’automatisation doit conserver cette séparation. « Hôte SSH vérifié » ne suffit pas pour déployer un secret ou effectuer une maintenance. Le compte, la commande, le périmètre de changement et l’idempotence de l’action ont leurs propres autorités.

Tests négatifs avec des noms complets

Résolvez le même nom court sous deux suffixes. Testez une même empreinte sous Secure, Insecure, Bogus et Indeterminate. Faites échouer SHA-256 tout en laissant SHA-1 correspondre. Opposez une clé locale à un nouveau SSHFP. Utilisez deux ports et un bastion. Copiez la clé privée sur un second endpoint. Puis validez l’hôte tout en refusant séparément l’utilisateur et la commande.

Chaque résultat doit nommer le propriétaire DNS, l’état de validation, la clé, le port, la liaison, la politique et la permission suivante. Un pass sans sujet est une nouvelle vulnérabilité documentaire.