Blocs Match de la configuration SSH et approbation de l'agent

Une approbation SSH n'a de sens que si la connexion approuvée est celle que SSH va réellement établir. Cela paraît évident, jusqu'à ce qu'un agent lance ssh prod, qu'un alias choisisse un autre HostName, qu'un bloc Match modifie l'utilisateur distant et que ProxyJump fasse passer la session par un bastion qui n'était mentionné nulle part dans la demande.

La plupart des erreurs de configuration SSH restent gérables lorsqu'une personne surveille le terminal. Elle voit une invite de clé d'hôte inconnue, remarque root@... ou sait que prod désigne autre chose sur le réseau du bureau. Un agent autonome n'a pas cette méfiance. Il utilise l'alias qui lui a été fourni et suit exactement la configuration.

C'est pourquoi les blocs Match de la configuration SSH doivent faire l'objet d'un audit de sécurité avant qu'un agent obtienne un accès SSH. L'objectif n'est pas d'interdire les alias, les bastions ou la configuration conditionnelle. Il faut que l'action demandée, la configuration SSH effective et la connexion approuvée par une personne décrivent la même chose.

Un alias d'hôte est une entrée, pas une identité

ssh app-prod ne vous indique ni où SSH va se connecter, ni quel compte il utilisera, ni quelle clé il proposera, ni si le trafic passera d'abord par une autre machine. Cette commande indique à OpenSSH quelle entrée de configuration utiliser en premier.

Cette différence est souvent masquée parce que les alias rendent le travail quotidien agréable. Un nom court comme app-prod est plus facile à saisir qu'un nom d'hôte complet avec un utilisateur précis et un port non standard. Il est aussi plus facile à transmettre à un agent. Mais l'alias n'est qu'une poignée. Son sens vient de tous les paramètres correspondants des fichiers de configuration lus par SSH.

OpenSSH lit d'abord les options de la ligne de commande, puis ~/.ssh/config, puis la configuration du système. Pour la plupart des options à valeur unique, la première valeur obtenue est celle utilisée. Le manuel ssh_config(5) d'OpenSSH en tire une règle pratique : placez les déclarations précises en premier et les valeurs par défaut générales ensuite. Un bloc Host * général placé trop haut peut neutraliser discrètement une règle conditionnelle plus attentive.

Commencez par un inventaire qui décrit chaque alias utilisable par un agent avec des éléments vérifiables :

N'écrivez pas « production » dans la colonne de destination. Écrivez la cible réelle utilisée par SSH. N'écrivez pas « utilisateur par défaut ». Écrivez deploy, ubuntu, ec2-user ou le compte reçu par le serveur. Si l'itinéraire comporte un hôte relais, nommez-le. Si l'alias se comporte différemment selon le réseau, créez une ligne distincte, car il s'agit d'une connexion effective différente.

La distinction utile est la suivante : un alias identifie une entrée de configuration ; une destination identifie le point d'accès distant. Les confondre conduit à de mauvaises approbations. Un responsable peut approuver l'ouverture d'une session vers staging-api tout en se trompant sur le point d'accès réel, parce que l'alias contient un comportement obsolète ou conditionnel.

Les alias devraient aussi décrire un objectif opérationnel, pas le dissimuler. prod-readonly, prod-deploy et prod-breakfix incitent à s'arrêter au bon endroit. Un alias unique nommé prod, qui choisit utilisateurs, clés et itinéraires dans des blocs conditionnels, économise quelques frappes et crée un problème permanent d'examen.

Les blocs Match sont une logique de connexion exécutable

Un bloc Match n'est pas une étiquette pour un groupe d'hôtes. C'est une section conditionnelle de ssh_config qui détermine quelles directives s'appliquent. Les conditions peuvent porter sur l'hôte demandé, l'hôte d'origine, l'utilisateur distant, l'utilisateur local, l'état de canonicalisation, le réseau local, une commande demandée ou une commande exec exécutée par SSH via le shell local.

Cette puissance est utile. Elle signifie aussi qu'une configuration peut contenir un comportement invisible si l'on inspecte seulement l'alias Host voisin.

Considérez cette configuration :

Host prod-api
    HostName api-01.prod.example.net
    User deploy
    ProxyJump prod-bastion

Match originalhost prod-api user root
    IdentityFile ~/.ssh/breakfix_ed25519
    IdentitiesOnly yes

Une personne qui ne lit que le bloc Host prod-api voit une connexion de déploiement avec l'utilisateur deploy. Si l'appelant exécute ssh -l root prod-api, la condition Match originalhost prod-api user root peut s'appliquer. La prise en compte de l'identité dépend aussi de l'endroit où les paramètres précédents ont été obtenus et du fait que l'option accepte ou non plusieurs valeurs. L'essentiel est plus simple : la connexion a changé à cause d'un argument utilisateur sur la ligne de commande, et non parce que l'alias a changé.

Pour les agents, évitez les règles Match user qui accordent une identité ou un itinéraire plus privilégié. Elles semblent propres parce qu'elles regroupent le comportement par nom de compte. Mais un outil appelant peut facilement les modifier avec -l, user@host ou une commande générée. Placez plutôt l'utilisateur prévu directement dans un alias correspondant à un objectif précis.

Une version plus sûre rend chaque intention explicite :

Host prod-deploy
    HostName api-01.prod.example.net
    User deploy
    ProxyJump prod-bastion
    IdentityFile ~/.ssh/prod_deploy_ed25519
    IdentitiesOnly yes

Host prod-breakfix
    HostName api-01.prod.example.net
    User ops
    ProxyJump prod-bastion
    IdentityFile ~/.ssh/prod_breakfix_ed25519
    IdentitiesOnly yes

Cela ne rend pas l'accès privilégié inoffensif. Cela rend la connexion demandée compréhensible. Un agent doit recevoir une autorisation distincte pour appeler prod-breakfix ; il ne peut pas adopter ce comportement par hasard en changeant simplement un nom d'utilisateur.

Match exec mérite encore moins de confiance dans une configuration destinée aux agents. Il exécute une commande shell locale pendant l'évaluation de la configuration SSH. Les équipes l'utilisent pour détecter le réseau, consulter un inventaire ou sélectionner des identifiants. Une tentative de connexion SSH devient alors un chemin de code local dépendant de l'environnement. Si cette souplesse est nécessaire au travail humain, gardez ces alias en dehors de l'ensemble appelable par un agent. Un examen de connexion ne devrait pas exiger la rétro-ingénierie d'une commande shell arbitraire.

La première valeur correspondante peut neutraliser votre exception

Le problème le plus tenace d'une configuration SSH n'est pas une section invalide. C'est une section valide placée après une règle plus générale qui a déjà défini l'option.

Supposons qu'un développeur écrive ceci pour imposer un bastion à la production :

Host *
    User deploy
    ProxyJump dev-bastion

Host prod-*
    ProxyJump prod-bastion

L'attente est compréhensible : prod-* semble plus précis et devrait donc l'emporter. OpenSSH ne trie pas les blocs selon leur précision. Il les traite dans l'ordre du fichier et, pour de nombreuses directives, la première valeur obtenue l'emporte. prod-api conservera dev-bastion, car le bloc Host * précédent a déjà fourni ProxyJump.

Placez les blocs précis en premier :

Host prod-*
    ProxyJump prod-bastion

Host *
    User deploy
    ServerAliveInterval 30

Ce n'est pas qu'une question de style. Un itinéraire passant par le mauvais bastion peut placer la session sur le mauvais chemin réseau. Une valeur par défaut générale User deploy peut amener un alias de production à s'authentifier avec un compte qui n'a rien à faire sur cet hôte. Un IdentityFile général peut proposer un identifiant inattendu avant celui qui était prévu.

Il ne faut toutefois pas appliquer aveuglément la règle de la première valeur. Certaines directives acceptent volontairement plusieurs valeurs, et IdentityFile en est un exemple courant. Plusieurs identités configurées peuvent être ajoutées à l'ensemble examiné par SSH. Le problème devient alors différent : un alias précis peut nommer la bonne identité tout en laissant disponibles d'autres identités provenant d'une configuration précédente ou de l'agent SSH local.

Pour les connexions automatisées, rendez la sélection de l'identité explicite et prévisible :

Host prod-deploy
    HostName api-01.prod.example.net
    User deploy
    IdentityFile ~/.ssh/prod_deploy_ed25519
    IdentitiesOnly yes
    ProxyJump prod-bastion

IdentitiesOnly yes indique à OpenSSH d'utiliser uniquement les identités configurées dans SSH ou fournies sur la ligne de commande, au lieu d'essayer librement toutes celles disponibles dans un agent. Cela ne répare pas une configuration négligée. En revanche, cela empêche une clé sans rapport chargée dans l'agent local de devenir une candidate par accident.

On recommande souvent de placer toutes les valeurs par défaut dans Host * et de ne les remplacer qu'en cas de besoin. C'est raisonnable pour des paramètres sans incidence sur l'autorité, comme les intervalles de maintien de connexion. C'est une mauvaise pratique pour le choix de l'utilisateur, les itinéraires, les fichiers d'identité, les ports, ProxyCommand et la réécriture des hôtes. Les valeurs par défaut qui influencent l'autorité doivent rester rares. Un peu de répétition coûte moins cher que d'expliquer pourquoi un agent a atteint la bonne machine par le mauvais chemin.

ProxyJump crée une autre connexion à examiner

ProxyJump n'est pas un simple attribut de la connexion vers la destination. SSH se connecte d'abord à l'hôte relais, puis établit depuis celui-ci un transfert TCP vers la destination. Plusieurs relais peuvent être indiqués et traversés dans l'ordre. Le manuel OpenSSH précise aussi que la configuration de l'hôte de destination ne s'applique généralement pas aux hôtes relais.

C'est souvent là que les examens échouent. Une configuration peut être précise pour prod-api et totalement vague pour prod-bastion.

Host prod-api
    HostName 10.40.8.17
    User deploy
    ProxyJump prod-bastion

Host prod-bastion
    HostName bastion.prod.example.net
    User jump
    IdentityFile ~/.ssh/bastion_ed25519
    IdentitiesOnly yes

Il s'agit de deux décisions d'authentification et de deux identités d'hôte :

1. SSH authentifie le client local auprès de bastion.prod.example.net avec le compte jump.
2. Le bastion transfère un flux TCP vers 10.40.8.17.
3. SSH s'authentifie à travers ce flux auprès de la destination avec le compte deploy.

L'hôte relais peut avoir une autre clé, un autre utilisateur, un autre port et un autre enregistrement de clé d'hôte. Il peut aussi être sélectionné par un alias générique ou un bloc conditionnel que personne ne vérifie, puisque l'agent n'a demandé que prod-api.

Examinez chaque étape avec ssh -G, pas seulement l'alias final :

ssh -G prod-api | egrep '^(hostname|user|port|proxyjump|identityfile|identitiesonly) '
ssh -G prod-bastion | egrep '^(hostname|user|port|identityfile|identitiesonly) '

La sortie contient une option par ligne. Un examen correct peut produire cette forme :

hostname api-01.prod.example.net
user deploy
port 22
proxyjump prod-bastion
identityfile ~/.ssh/prod_deploy_ed25519
identitiesonly yes

Vérifiez ensuite le bastion séparément. Si prod-api utilise une chaîne séparée par des virgules, comme edge-bastion,prod-bastion, exécutez la commande pour les deux alias. Une chaîne n'est pas un itinéraire opaque : elle correspond à plusieurs configurations distinctes du client SSH.

Évitez de définir un itinéraire relais générique dans Host * ou dans un motif large comme Host *.internal. Il risque de capter des hôtes temporaires, des environnements de staging et des alias ajoutés des mois plus tard. Définissez l'itinéraire dans les alias qui en ont besoin. Si plusieurs alias de production l'utilisent, créez un motif étroit réservé à ces alias et ne le réutilisez pas sans précaution.

Vérifiez également ProxyCommand. OpenSSH traite ProxyJump et ProxyCommand comme des options concurrentes : celle qui est spécifiée en premier empêche les occurrences ultérieures de l'autre de prendre effet. Une configuration qui semble utiliser un bastion peut en réalité exécuter une commande proxy précédente. Les deux paramètres doivent être signalés, car ils modifient l'origine de la connexion réseau et la manière dont elle atteint la destination.

Le choix de l'utilisateur modifie l'autorité approuvée

Le compte distant fait partie de l'action demandée. [email protected] et [email protected] peuvent atteindre le même serveur, mais ils n'ont ni la même autorité, ni le même profil shell, ni les mêmes commandes forcées, droits sudo ou traces d'audit.

SSH peut obtenir l'utilisateur distant de plusieurs endroits : user@host dans la commande, ssh -l user host, une directive User ou, à défaut, le nom de l'utilisateur local. Un examen de configuration qui demande seulement « Quel hôte ? » est incomplet.

Utilisez des alias qui imposent un utilisateur lorsqu'un agent a une tâche définie :

Host inventory-read
    HostName inventory.prod.example.net
    User inventory_ro
    IdentityFile ~/.ssh/inventory_ro_ed25519
    IdentitiesOnly yes

Host inventory-deploy
    HostName inventory.prod.example.net
    User deploy
    IdentityFile ~/.ssh/inventory_deploy_ed25519
    IdentitiesOnly yes

Ne donnez pas à un agent un nom d'hôte générique en espérant qu'une invite ou un wrapper le maintiendra sur le bon compte. Un générateur de commandes peut produire [email protected] aussi facilement que [email protected]. La configuration doit rendre le chemin autorisé facile et les chemins privilégiés clairement distincts.

Testez les variantes qu'un outil peut générer :

ssh -G inventory-read | grep '^user '
ssh -G -l ops inventory-read | grep '^user '
ssh -G ops@inventory-read | grep '^user '

Si la deuxième ou la troisième commande produit un compte que vous n'aviez pas prévu de laisser utiliser à un agent, la configuration n'est pas validée. Corrigez l'interface appelante ou isolez l'alias. Un bloc Match user peut également s'activer avec l'une de ces variantes, ce qui justifie un test explicite plutôt qu'une simple lecture.

Pour les équipes, réservez l'accès root à un alias d'urgence nommé séparément et gardez-le hors des permissions ordinaires de l'agent. Masquer User root derrière une condition Match est pire que de l'écrire clairement. La condition devient une chasse au trésor pendant un incident, et un appelant peut parfois la satisfaire en modifiant un paramètre de la ligne de commande.

IdentityFile contrôle plus que le chemin de la clé

IdentityFile semble ne servir qu'à sélectionner un fichier. En pratique, il détermine quel identifiant SSH peut présenter, et donc quelles règles d'autorisation distantes le serveur évaluera.

Voici un échec fréquent :

Host *
    IdentityFile ~/.ssh/id_ed25519

Host prod-*
    IdentityFile ~/.ssh/prod_ed25519

L'opérateur pense que la production utilise prod_ed25519. SSH peut avoir les deux fichiers d'identité dans sa liste de candidats, car IdentityFile accepte plusieurs entrées. Si un agent SSH contient d'autres clés et que IdentitiesOnly est absent, celles-ci peuvent aussi être proposées. Certains serveurs rejettent tôt les propositions répétées, d'autres acceptent une identité inattendue qui donne par hasard accès. Aucun de ces résultats n'exprime clairement l'intention.

Un alias destiné à un agent doit exprimer un objectif d'identité unique et limiter les propositions :

Host reports-export
    HostName reports.prod.example.net
    User exporter
    IdentityFile ~/.ssh/reports_export_ed25519
    IdentitiesOnly yes

Examinez ensuite la configuration effective au lieu de faire confiance à la section :

ssh -G reports-export | grep '^identityfile '
ssh -G reports-export | grep '^identitiesonly '

Plusieurs lignes identityfile ne sont pas automatiquement incorrectes. Les configurations fondées sur des certificats et une rotation planifiée des clés peuvent le justifier. Mais chaque identité listée doit appartenir à la même frontière d'autorité. Si un alias peut proposer une clé personnelle d'administrateur, une ancienne clé de déploiement et une clé d'automatisation de production, son histoire d'autorisation n'est pas claire.

Ne résolvez pas le problème en stockant des clés privées dans les fichiers, l'environnement, les invites ou les scripts générés de l'agent. Vous ne feriez que transformer une ambiguïté de configuration en exposition d'identifiants. Sallyport conserve les clés SSH dans son coffre chiffré et exécute les actions SSH par son intermédiaire, mais ne peut pas rendre honnête une configuration SSH ambiguë. L'alias, l'itinéraire, l'utilisateur et l'intention liée à l'identité doivent rester clairs avant l'approbation de l'agent.

La même règle vaut pour les noms de clés. Un chemin comme ~/.ssh/id_ed25519 n'indique pas l'usage prévu. prod_deploy_ed25519 est préférable, mais la configuration doit encore expliquer quels groupes d'hôtes, quel utilisateur et quel itinéraire l'utilisent. Les noms de fichiers facilitent l'examen, ils ne le remplacent pas.

La canonicalisation peut faire correspondre un alias deux fois

La canonicalisation des noms d'hôte est l'un des moyens les moins visibles par lesquels SSH modifie une configuration. Lorsque CanonicalizeHostname yes est activé, OpenSSH peut prendre un nom incomplet, lui ajouter des suffixes de domaine configurés, le résoudre, puis relire la configuration avec la nouvelle cible. Match canonical s'applique lors de cette seconde passe. Match final demande une analyse finale et correspond pendant cette passe ; lorsque la canonicalisation est activée, les conditions canonical et final correspondent ensemble.

Ce comportement peut être utile dans de grands réseaux internes. Il peut aussi transformer un alias court en piège de configuration conditionnelle.

CanonicalizeHostname yes
CanonicalDomains corp.example.net

Host build
    User ci

Match canonical host *.prod.example.net
    ProxyJump prod-bastion

L'appelant saisit ssh build. La première passe voit build. Si la canonicalisation résout ce nom en build.prod.example.net, SSH relit la configuration et le bloc Match canonical host *.prod.example.net peut définir une route de production. La connexion n'a pas changé parce que l'appelant a demandé un autre alias. Elle a changé parce que le DNS et une seconde passe ont modifié l'hôte vu par les règles suivantes.

Le manuel OpenSSH distingue deux conditions souvent confondues :

• Match originalhost teste le jeton d'hôte fourni par l'appelant.
• Match host teste la cible après substitution de HostName ou canonicalisation.

Utilisez originalhost lorsque le comportement doit être lié à un alias nommé intentionnellement. Utilisez host lorsque le comportement doit dépendre de la destination réellement résolue. N'utilisez ni l'un ni l'autre à la légère pour modifier des privilèges.

La canonicalisation comporte une autre subtilité avec les bastions. CanonicalizeHostname yes ne s'applique normalement pas aux connexions utilisant ProxyCommand ou ProxyJump ; CanonicalizeHostname always l'étend aux connexions passant par un proxy. Deux alias qui semblent structurés de la même façon peuvent donc suivre des règles de réécriture différentes simplement parce que l'un possède un hôte relais.

Pour les permissions d'un agent, la politique la plus simple est souvent la meilleure : désactivez la canonicalisation pour les alias remis à un agent et utilisez des valeurs HostName complètes et explicites. Si votre environnement exige la canonicalisation, testez chaque alias autorisé dans le contexte réseau exact où l'agent s'exécute. Ne supposez pas qu'un nom court sera résolu de la même façon sur un réseau domestique, un réseau d'entreprise, un VPN et le Wi-Fi du bureau.

Match localnetwork pose le même problème. OpenSSH précise que l'adresse du réseau local n'est pas fiable pour une configuration sensible à la sécurité, notamment sur les réseaux configurés par DHCP. Elle convient aux réglages pratiques. Ne l'utilisez pas pour décider si un agent reçoit une identité plus privilégiée, contourne un bastion ou atteint la production.

Rendez la connexion visible avant de l'autoriser

ssh -G est le moyen le plus rapide de transformer une configuration SSH en quelque chose de testable. Il affiche la configuration utilisée par SSH après le traitement des règles Host et Match, puis quitte sans ouvrir de connexion.

Exécutez-le avec l'alias et les arguments exacts utilisés par l'agent. Ne testez pas seulement une version nettoyée de la commande.

ssh -G prod-deploy | egrep '^(hostname|user|port|proxyjump|proxycommand|identityfile|identitiesonly|canonicalizehostname) '

Pour un audit sérieux, enregistrez la sortie complète comme référence dans le dépôt qui contient l'automatisation. Utilisez un fichier de configuration explicitement nommé afin que le test n'hérite pas silencieusement des paramètres personnels d'un développeur :

ssh -F ./agent-ssh-config -G prod-deploy > ./testdata/prod-deploy.effective

Examinez cette référence lorsque la configuration change. Une différence utile détecte une modification de hostname, user, proxyjump ou de la liste d'identités avant qu'elle n'atteigne un processus d'approbation. Une comparaison complète et bruyante vaut mieux que de faire confiance à une section copiée dans une demande de modification.

N'utilisez ssh -vvv qu'après avoir vérifié que ssh -G affiche les valeurs attendues. Les journaux détaillés aident à confirmer les clés d'hôte et les méthodes d'authentification réellement tentées par SSH, mais ils mélangent décisions de configuration et bruit réseau. -G répond d'abord à la question « Que dit cette configuration ? ». C'est ce qu'il faut établir avant de chercher un problème d'accès.

Testez volontairement les variantes :

ssh -F ./agent-ssh-config -G prod-deploy
ssh -F ./agent-ssh-config -G -l ops prod-deploy
ssh -F ./agent-ssh-config -G ops@prod-deploy
ssh -F ./agent-ssh-config -G prod-deploy.prod.example.net

Les résultats doivent rester dans la frontière d'autorité attendue ou échouer. Si un remplacement d'utilisateur modifie le compte, si une forme complète contourne le bastion ou si un nom court obtient une autre identité après canonicalisation, vous avez trouvé un chemin de configuration à fermer.

Vérifiez aussi les fichiers inclus. Include peut faire du ~/.ssh/config une simple porte d'entrée vers un répertoire rempli de règles générées par la machine, l'entreprise ou le projet. Examinez la sortie effective avec le même compte local et le même chemin de configuration que ceux utilisés par l'agent. Tester depuis votre shell alors que l'agent utilise un autre compte donne une fausse impression de certitude.

Gardez une configuration SSH réduite et conçue pour les agents

La meilleure configuration SSH pour un agent de programmation autonome n'est généralement pas votre configuration personnelle à laquelle vous avez ajouté quelques commentaires. Les configurations personnelles accumulent raccourcis, exceptions de client, anciens alias, comportements liés au réseau local, agents transférés et identités qui ont été pratiques un jour. Un agent a besoin d'un catalogue de connexions limité.

Créez un fichier de configuration dédié qui ne contient que les alias approuvés et les hôtes relais nécessaires. Dirigez l'agent ou son wrapper d'exécution vers ce fichier avec -F. Donnez à chaque alias une seule fonction, un HostName, un utilisateur, un itinéraire et une intention d'identité explicites. Évitez la logique conditionnelle sauf si vous pouvez démontrer qu'un alias statique ne suffit pas.

Un exemple compact :

Host prod-bastion
    HostName bastion.prod.example.net
    User jump
    IdentityFile ~/.ssh/prod_bastion_ed25519
    IdentitiesOnly yes

Host prod-deploy
    HostName api-01.prod.example.net
    User deploy
    ProxyJump prod-bastion
    IdentityFile ~/.ssh/prod_deploy_ed25519
    IdentitiesOnly yes

Host staging-deploy
    HostName api-01.staging.example.net
    User deploy
    IdentityFile ~/.ssh/staging_deploy_ed25519
    IdentitiesOnly yes

Cette configuration se répète. C'est une bonne chose. Le fichier indique au responsable ce que signifie chaque connexion sans lui demander d'exécuter mentalement la priorité des jokers et l'état des conditions.

Ne confondez pas un fichier dédié avec un moteur de politique. Il ne peut pas prouver qu'une commande est sûre après l'ouverture de la session. Il peut rendre la connexion de transport suffisamment concrète pour être examinée : cet alias, ce point d'accès, cet utilisateur, cet itinéraire, cette identité. C'est une limite utile.

Les autorisations par session et les journaux d'activité de Sallyport donnent aux opérateurs un point de contrôle humain et une trace des actions de l'agent, mais la configuration SSH fournit toujours les faits qui sous-tendent l'action. Si prod-deploy peut se transformer en plusieurs chemins réseau ou comptes, la configuration a déjà rendu l'approbation moins fiable.

Avant d'autoriser un agent à utiliser un alias SSH, rendez-le effectif, examinez chaque hôte relais et testez les variantes de ligne de commande que l'agent peut produire. Si la connexion effective vous surprend une fois, supposez qu'elle surprendra quelqu'un au pire moment. Corrigez l'alias jusqu'à ce qu'il ressemble à une approbation qu'une personne peut réellement donner.