La canonicalisation SSH peut-elle changer la cible approuvée ?

Une approbation qui indique ssh build n'autorise pas forcément la machine qui reçoit la connexion TCP. OpenSSH peut développer ce nom court, suivre un CNAME autorisé, relire sa configuration, choisir un autre utilisateur ou port, puis résoudre le nom obtenu vers une adresse parmi plusieurs. Si une passerelle pour agents n'approuve que le texte fourni par l'agent, son approbation peut décrire une cible alors que le client SSH en utilise une autre.

Ce constat ne condamne pas la canonicalisation. Les noms courts sont pratiques, les noms canoniques simplifient la gestion de la configuration et les clés d'hôte continuent d'authentifier les serveurs. Il faut placer la limite d'approbation après le calcul de la destination effective par OpenSSH, mais avant l'ouverture du socket. La personne qui approuve doit voir le nom demandé, le nom final et l'adresse, ainsi que toute modification importante issue de la configuration.

Une commande SSH porte quatre identités différentes

Une cible SSH n'est pas une simple chaîne. La traiter ainsi crée précisément le défaut abordé ici. Un processus d'approbation sérieux sépare quatre identités :

• Le nom demandé est l'argument fourni par l'agent, comme build.
• Le nom d'hôte effectif est la valeur utilisée par OpenSSH après la substitution de Hostname et la canonicalisation, comme build.ops.example.
• L'adresse du pair est l'adresse IP choisie lorsque le client ouvre le socket.
• L'identité authentifiée est la clé ou le certificat d'hôte accepté pour cette connexion.

Ces valeurs répondent à des questions différentes. Le nom demandé consigne l'intention. Le nom effectif contrôle les correspondances de configuration suivantes et, en général, la recherche de clé d'hôte. L'adresse indique où sont partis les paquets. La clé d'hôte indique quel serveur a prouvé qu'il détenait une clé privée. L'approbation a besoin des trois premières avant la connexion, et le résultat d'audit doit ajouter la quatrième après l'échange de clés.

OpenSSH expose lui-même cette distinction dans ssh_config. Le jeton %n désigne le nom d'hôte distant d'origine fourni en ligne de commande, alors que %h désigne le nom distant après traitement de la configuration. %k est encore une autre valeur : HostKeyAlias lorsqu'il est défini, sinon le nom d'origine. Ces jetons existent parce qu'OpenSSH ne peut pas supposer sans risque que chaque étape utilise le même nom.

Cette distinction explique aussi pourquoi une vérification réussie de la clé d'hôte ne répare pas une autorisation vague. L'authentification peut prouver que le point de terminaison détient une clé attendue. Elle ne peut pas prouver que la personne souhaitait autoriser ce point lorsque la carte affichait seulement build. L'autorisation demande si cette action peut atteindre cette destination. L'authentification demande si le serveur qui répond correspond à une identité enregistrée. Les deux contrôles comptent et interviennent à des moments différents.

La canonicalisation peut réécrire le nom avant la connexion

CanonicalizeHostname détermine si OpenSSH effectue une réécriture explicite. Sa valeur par défaut, no, laisse toutes les recherches au résolveur du système. Avec yes, OpenSSH essaie les suffixes de CanonicalDomains pour les connexions directes. Avec always, il canonicalise aussi les destinations atteintes par ProxyCommand ou ProxyJump.

Supposons que l'agent demande cette action :

host: build
user: deploy
command: /usr/local/bin/release status

Le client peut contenir cette configuration :

Host *
    CanonicalizeHostname yes
    CanonicalDomains ops.example
    CanonicalizeFallbackLocal no
    CanonicalizeMaxDots 1
    CanonicalizePermittedCNAMEs *.ops.example:*.hosts.example

OpenSSH essaie d'abord build.ops.example. Si DNS renvoie un CNAME autorisé vers build-07.hosts.example, cette cible peut devenir le nom canonique. La demande indique toujours build, mais le client ne se connecte plus sous ce nom. Une carte qui n'affiche que la demande masque la transformation qui importe.

Les limites méritent de l'attention. CanonicalizeMaxDots vaut 1 par défaut, donc un nom comportant un point reste éligible, pas seulement une étiquette simple. CanonicalizeFallbackLocal vaut yes par défaut ; si les domaines canoniques configurés ne donnent rien, OpenSSH peut transmettre le nom d'origine au résolveur et à ses règles de recherche. no rend l'échec explicite. Ce comportement convient mieux à une passerelle d'approbation, car la liste de recherche locale peut varier avec le réseau et le temps.

Le suivi des CNAME est limité séparément. CanonicalizePermittedCNAMEs vaut none par défaut et ses règles associent des motifs source autorisés à des motifs cible. Ce choix est raisonnable. Une règle large telle que *:* transforme les alias DNS en étape de réécriture sans limite. Une règle étroite documente la transition d'espace de noms réellement attendue, par exemple des alias de service de ops.example vers les hôtes de hosts.example.

Le manuel OpenSSH décrit précisément ces contrôles, mais une couche d'approbation ne peut pas recopier leurs valeurs sur une carte. Elle doit exécuter le même calcul avec la même configuration client. Réimplémenter la recherche des suffixes et les règles CNAME dans le service d'approbation crée souvent un écart avec le client au fil des versions et des changements locaux.

La seconde lecture modifie plus que DNS

Lorsque la canonicalisation est active, OpenSSH traite de nouveau sa configuration avec le nouveau nom cible. Cette seconde passe peut activer des blocs Host et Match qui ne correspondaient pas à l'alias d'origine. Une vérification limitée à DNS peut donc manquer d'autres modifications de la destination.

Prenons un nom canonique qui correspond à ce bloc :

Match canonical host *.prod.ops.example
    User release
    Port 2222
    IdentityFile ~/.ssh/prod_release
    ProxyJump bastion.ops.example

Une demande pour deploy peut d'abord devenir deploy.prod.ops.example, puis adopter un autre utilisateur distant, un autre port, un autre fichier d'identité et un hôte de saut. OpenSSH retient la première valeur obtenue pour la plupart des directives. L'application de ces réglages dépend donc des blocs précédents et de leur ordre. La lecture isolée du bloc correspondant ne révèle pas la configuration finale.

La condition canonical correspond uniquement pendant la relecture qui suit la canonicalisation. La condition final demande une dernière lecture même lorsque celle-ci est désactivée. Lorsqu'elle est active, canonical et final correspondent pendant la même passe. host s'applique à la cible après substitution par Hostname ou canonicalisation, tandis que originalhost s'applique à la valeur de la ligne de commande. Ces détails rendent une configuration apparemment simple très dépendante de son état.

Le schéma dangereux consiste à approuver host=deploy, user=agent, port=22, à confier ensuite ssh deploy à un client ordinaire et à supposer que ces champs restent vrais. Si la configuration peut encore modifier User, Port, ProxyJump, RemoteCommand, les redirections ou le choix d'identité, l'approbation couvre une proposition et non l'action exécutée.

Une conception plus sûre fige la configuration effective importante après la dernière passe. Elle lie au minimum l'hôte, l'adresse sélectionnée, le port, l'utilisateur distant, le parcours du proxy, la commande distante, les redirections demandées, l'alias de clé et la source d'identité. Si une valeur change avant la connexion, elle annule l'approbation et la redemande. Une seconde évaluation ne doit jamais conserver silencieusement l'ancien accord.

La provenance de la configuration appartient à la cible

La destination finale dépend des fichiers, des options de ligne de commande, de l'environnement et du réseau local évalués par OpenSSH. Approuver sans consigner ces entrées permet au sens approuvé de changer facilement. Le manuel donne l'ordre habituel suivant : options de ligne de commande, fichier utilisateur, puis fichier système. Pour la plupart des directives, la première valeur obtenue l'emporte.

Un agent autorisé à ajouter des options SSH arbitraires peut contourner une valeur prudente. -F choisit un autre fichier, tandis que -o peut définir directement Hostname, ProxyCommand, ProxyJump, Port, User, HostKeyAlias ou des redirections. La passerelle doit analyser une action SSH en champs typés et refuser les options inconnues au lieu d'accepter une chaîne opaque. Si des options brutes sont nécessaires, elle doit classer chacune de celles qui touchent la destination et inclure sa valeur normalisée dans l'approbation.

Les fichiers apportent aussi des entrées transitives. Include accepte plusieurs chemins, des jokers, des jetons et des variables d'environnement, puis traite les correspondances par ordre lexical. L'ajout d'un fichier dans un dossier inclus peut donc changer la première valeur sans toucher au fichier principal. Consignez le condensat et le propriétaire de chaque fichier chargé, pas seulement le chemin du premier. Refusez les fichiers modifiables par l'agent ou par le dossier de travail d'un dépôt non fiable.

Match exec ne compare pas simplement une condition : OpenSSH exécute la commande indiquée dans le shell de l'utilisateur et considère un code zéro comme une correspondance. Match localnetwork peut changer la configuration selon les adresses des interfaces actives. Le manuel avertit lui-même qu'un réseau observé localement n'est pas fiable pour une configuration sensible lorsqu'il vient de DHCP. La même demande ssh build peut donc produire une autre cible après la connexion d'un VPN, un changement de résultat de script ou l'apparition d'un fichier inclus.

L'exécuteur doit établir un ensemble fermé d'entrées avant l'évaluation. Utilisez un binaire fixe, une racine de configuration contrôlée, un environnement nettoyé, des propriétaires connus, une famille d'adresses explicite et une politique déclarée pour les fichiers utilisateur et système. Calculez un condensat de cet ensemble et placez-le dans le ticket. Il n'a pas besoin d'occuper le premier plan sur la carte, mais il doit figurer dans l'audit et être revérifié au moment de l'usage.

Figer la configuration n'oblige pas à interdire les réglages utiles par hôte. Il faut décider qui peut les écrire. Un alias géré par l'exploitant qui relie build à un hôte de production peut être sûr si la carte affiche cette association. Un alias créé dans un dépôt contrôlé par l'agent appartient à la demande non fiable, même si sa syntaxe ressemble à une configuration OpenSSH ordinaire.

Ce contrôle de provenance ferme aussi une lacune fréquente des tests. Les équipes testent souvent avec un fichier temporaire propre, puis exécutent avec toute la configuration du développeur et les valeurs du système. Le test prouve le fichier temporaire, pas l'action réelle. Capturez une fois les entrées exactes et conservez-les jusqu'à la connexion.

Traitez également la version d'OpenSSH comme une entrée. Les valeurs par défaut et les directives acceptées changent, et un parc peut contenir plusieurs versions même si toutes les machines lisent le même fichier. Consignez le chemin de l'exécutable et sa version dans le ticket, puis relancez les tests de compatibilité avant une mise à niveau. Un analyseur écrit pour une version doit refuser une sortie inconnue au lieu de deviner qu'un champ renommé ou ajouté est sans effet.

La provenance décide aussi si une approbation peut être réutilisée. Cette réutilisation n'est défendable que lorsque la demande, la configuration complète, le résultat de résolution et l'état du connecteur restent identiques pendant une courte durée. Un surnom identique ne prouve rien de tout cela. Une nouvelle approbation concise vaut mieux qu'une permission durable dont la cible effective peut dériver entre les exécutions de l'agent.

Les réponses DNS peuvent changer après l'affichage

Même si le nom effectif reste fixe, son adresse peut changer entre l'approbation et la connexion. Rotation DNS, vues séparées, changement de VPN, chemins de recherche et mises à jour ordinaires peuvent tous fournir une autre réponse. Un écart classique entre contrôle et usage apparaît si le service résout le nom, affiche une adresse, puis laisse le processus SSH la résoudre de nouveau.

La solution n'est pas de déclarer DNS non fiable et d'ignorer l'adresse. Il faut lier l'exécution au résultat exact vu par la personne. Résolvez une seule fois dans l'exécuteur de confiance, choisissez une adresse selon les règles de famille du client, affichez-la et transmettez cette adresse de socket à la connexion sans nouvelle résolution. Conservez le nom canonique pour les usages d'identité applicables, la recherche de clés, les certificats et les journaux, mais ne laissez pas le transport choisir une nouvelle adresse.

Plusieurs enregistrements A ou AAAA exigent une règle explicite. Afficher un ensemble et permettre au client d'en essayer un membre peut convenir, mais la carte doit préciser qu'elle couvre cet ensemble et l'audit doit consigner celui qui a fonctionné. Si l'ensemble change, l'ancienne approbation ne doit pas s'étendre à la nouvelle adresse. Pour les hôtes sensibles, approuver une seule adresse est plus facile à comprendre.

Un proxy change l'endroit où la résolution DNS locale a lieu. Avec ProxyJump, le client demande généralement à la connexion de saut de transporter le trafic vers l'hôte et le port finaux. ProxyCommand peut mettre en œuvre presque n'importe quel transport. L'adresse du pair visible localement peut appartenir au proxy tandis que le nom final est résolu ailleurs. L'approbation doit couvrir les deux étapes : le point du proxy atteint localement et la valeur finale transmise. Prendre l'adresse du proxy pour la cible perd la destination ; l'ignorer perd le chemin réseau.

Une clé valide ne valide pas le nom demandé

La vérification stricte des clés protège une autre limite que l'approbation de cible. Elle doit rester active, mais ne peut pas savoir si la canonicalisation correspond à l'intention humaine. Des clés partagées, des certificats avec plusieurs noms principaux ou un HostKeyAlias explicite peuvent produire une connexion cryptographiquement valide sous un nom différent de celui affiché.

L'architecture SSH de RFC 4251 décrit une base locale qui associe le nom saisi par l'utilisateur à une clé d'hôte. OpenSSH ajoute à ce modèle des noms dictés par la configuration. HostKeyAlias ordonne au client d'utiliser un alias au lieu du vrai nom pour lire ou enregistrer les clés et valider les certificats. C'est utile pour les tunnels et plusieurs serveurs sur une adresse, mais cela crée un nom supplémentaire à consigner.

RFC 4255, qui définit SSHFP, est particulièrement pertinent. Il avertit des noms non qualifiés et des chemins de recherche DNS injectés, et recommande dans ce cas de consulter la base locale avant l'empreinte DNS. Il précise aussi qu'un enregistrement SSHFP non authentifié par DNSSEC ne doit pas être considéré comme fiable. Ce conseil concerne l'authentification, mais confirme l'idée générale : développer un nom change le contexte de sécurité et la réponse du résolveur ne prouve pas l'identité.

RFC 4462 formule un avertissement plus net pour GSS-API. Une implémentation ne doit pas utiliser une réponse DNS non protégée pour construire le nom cible, car un attaquant pourrait modifier un alias ou une adresse et usurper le serveur. Même avec une authentification ordinaire par clé publique, la leçon reste valable. Une réécriture de nom non protégée ne doit pas décider en silence de l'identité qu'un contrôle prétend avoir approuvée.

La vérification de clé doit rattacher le résultat au dossier préparatoire. Consignez l'empreinte présentée, le nom ou l'alias utilisé, la correspondance éventuelle du nom principal du certificat et le résultat du contrôle strict. Si le client demande d'accepter une nouvelle clé, il s'agit d'une nouvelle décision de sécurité. Un processus autonome ne doit pas l'accepter automatiquement parce qu'une commande shell a déjà été approuvée.

La vérification préalable doit reprendre les mêmes entrées

Une bonne vérification reproduit la configuration finale du client et observe le chemin sans exécuter la commande distante. ssh -G affiche la configuration après évaluation des blocs Host et Match. ssh -vvv ajoute les diagnostics de résolution, de connexion et de clé ; le manuel fixe trois options -v comme niveau maximal.

Exécutez cette séquence dans un environnement contrôlé en remplaçant build par le jeton demandé exact :

ssh -G build | awk '
  $1 == "hostname" || $1 == "user" || $1 == "port" ||
  $1 == "proxyjump" || $1 == "proxycommand" ||
  $1 == "hostkeyalias" || $1 == "canonicalizehostname" {
    print
  }
'
ssh -vvv -o BatchMode=yes -o SessionType=none \
  -o ConnectTimeout=5 build 2>&1

La première commande produit une sortie de cette forme :

user deploy
hostname build-07.hosts.example
port 22
canonicalizehostname true
proxyjump none

L'exécution détaillée émet ensuite des lignes dont la formulation varie selon la version, mais elle identifie l'hôte développé, l'adresse et le port choisis, les passes de configuration et la clé proposée. Capturez des faits structurés dans l'exécuteur au lieu de prendre le texte de débogage pour une API stable. Ces commandes conviennent à une enquête manuelle ; la production doit obtenir les mêmes faits de l'implémentation qui ouvre le socket.

Ce diagnostic comporte deux pièges. D'abord, ssh -G montre la configuration évaluée, mais ne prouve pas l'adresse qu'une connexion atteindra. Ensuite, la sonde détaillée peut ouvrir une connexion et échanger des clés même avec SessionType=none ; ne l'exécutez que si la sonde est elle-même autorisée. BatchMode=yes supprime les demandes interactives, mais ne transforme pas la tentative en simple calcul local.

Pour une enquête reproductible, isolez toutes les entrées. Fournissez le fichier utilisateur prévu avec -F, tenez compte du comportement du binaire pour le fichier système, fixez les variables employées par Include ou les jetons et consignez la version. Notez aussi si un socket de contrôle peut réutiliser une connexion multiplexée. Une vérification sur des données fraîches sert peu si l'exécution rejoint une ancienne session maîtresse.

Ne lancez pas une analyse pour l'approbation puis une seconde pour l'exécution. L'architecture préférable utilise un exécuteur qui charge, canonicalise, résout, se met en pause avec un dossier candidat immuable, puis poursuit le même automate après l'accord. Si la bibliothèque ne peut pas se mettre en pause, créez un ticket signé ou authentifié qui contient tous les champs matériels et imposez au connecteur de refuser toute différence.

Le dossier d'approbation doit montrer la transformation

Une bonne carte rend le changement visible sans imposer la lecture d'un journal de débogage. Placez la cible demandée à côté de la cible effective et de l'adresse. Si rien n'a changé, dites-le brièvement. Si la canonicalisation ou un bloc Match a modifié un champ important, marquez l'ancienne et la nouvelle valeur.

Un dossier pratique peut prendre cette forme :

{
  "requested": {
    "host": "build",
    "user": "deploy",
    "command": "/usr/local/bin/release status"
  },
  "effective": {
    "host": "build-07.hosts.example",
    "address": "192.0.2.44",
    "port": 22,
    "user": "deploy",
    "proxy": null,
    "host_key_alias": null
  },
  "resolution": {
    "canonicalized": true,
    "source": "build.ops.example",
    "permitted_cname": true
  },
  "binding": "sha256:REDACTED"
}

La liaison doit couvrir un encodage déterministe des champs demandés et effectifs, la commande distante, les redirections, l'identité de configuration, l'adresse ou l'ensemble approuvé et une courte expiration. Le connecteur la recalcule juste avant d'ouvrir le socket. Si DNS, la configuration, la commande, l'utilisateur, le port ou le proxy diffère, il s'arrête.

Ne retirez pas un champ de la carte parce qu'il figure dans la liaison. Une personne autorise ce qu'elle voit. Affichez build -> build-07.hosts.example (192.0.2.44) comme une transformation lisible, puis l'utilisateur, le port, le proxy et la commande. Réservez les empreintes brutes et la provenance à une vue détaillée, sauf si une identité nouvelle ou modifiée exige l'attention.

Le cas difficile est un nom qui se résout vers un grand groupe volatil. N'approuvez pas une notion illimitée comme toute adresse actuelle de ce nom. Choisissez un candidat, approuvez un ensemble publié et borné avec expiration, ou exigez une identité stable plus forte, telle qu'un nom principal de certificat signé par une CA de confiance. Le modèle doit être déclaré, pas deviné par le connecteur.

Les proxies et la réutilisation exigent des liaisons distinctes

La canonicalisation se comporte différemment avec les proxies. CanonicalizeHostname yes ne s'applique qu'aux connexions sans ProxyCommand ni ProxyJump ; always inclut les connexions par proxy. Ce seul mot peut changer le nom final et activer la seconde lecture. Le système doit consigner la valeur réelle, sans supposer une activation générale.

Chaque hôte de saut est une connexion SSH avec son nom demandé, son nom effectif, son adresse, son utilisateur, son port et sa clé authentifiée. La cible finale conserve aussi son identité à travers le tunnel. N'approuver que l'étiquette finale omet un saut compromis ou inattendu. N'approuver que le serveur de saut omet la destination vers laquelle il transmet le flux.

Le multiplexage crée un contournement moins évident. Si une session ControlMaster correspondante existe, un nouvel appel peut la réutiliser au lieu de créer la connexion prévue. Le maître peut avoir résolu DNS auparavant, utilisé une ancienne configuration et authentifié une clé avant l'approbation actuelle. Désactivez la réutilisation pour les actions contrôlées ou liez l'approbation à l'identité immuable de la session maîtresse et vérifiez-la avant d'ouvrir un canal.

La même règle vaut pour les nouvelles tentatives. Après l'échec d'une adresse, la suivante reste autorisée uniquement si elle figurait dans l'ensemble affiché. Un proxy de secours, un autre port ou un nom nouvellement canonicalisé ne sont pas de simples détails de transport. Ils changent l'objet de l'autorisation et imposent une nouvelle décision.

L'audit doit conserver l'intention et le résultat

Une entrée utile permet de reconstruire toute la transformation sans relancer DNS. Conservez la demande d'origine, les champs effectifs, le nom canonique, la chaîne DNS, les adresses candidates, celle choisie, les sauts, l'empreinte acceptée, le nom principal du certificat et la commande ou le sous-système. Horodatez séparément la résolution et la connexion afin de rendre l'écart visible.

Sallyport achemine les actions SSH par son utilitaire sp-ssh tandis que les clés restent dans son coffre chiffré, de sorte que l'agent ne reçoit jamais la clé privée. Ses journaux Activity et Sessions proviennent d'un même journal chiffré et chaîné par hachage, ce qui permet au parcours d'approbation et d'exécution de conserver la cible demandée et la cible observée plutôt qu'une simple chaîne ressemblant à une commande.

La conservation ne suffit pas. Définissez des invariants testables : l'adresse exécutée appartenait à l'ensemble approuvé, l'hôte et le port correspondaient au ticket, l'identité acceptée a été consignée et chaque nouvelle tentative ou saut avait une autorisation. Donnez au test CanonicalizeHostname, un CNAME permis, un bloc Match canonical et deux réponses DNS. Modifiez un fait entre la vérification et la connexion, puis vérifiez que l'exécution s'arrête.

L'échec à éviter est banal : l'agent demande build, une personne reconnaît le surnom et approuve, puis un client sur un autre réseau le développe vers un autre domaine. La session peut rester chiffrée et le serveur peut présenter une clé valide pour son propre nom. L'approbation reste fausse. Réunissez le nom demandé, le nom final et l'adresse choisie dans une seule décision, puis exigez du connecteur qu'il prouve avoir utilisé exactement ces valeurs.