Résumé

  • L’agent décrit par RFC 9987 conserve les clés privées et répond à des requêtes : chargement, retrait, inventaire, verrouillage et signature. Le protocole de base n’authentifie pas son client ; la protection du point de connexion porte donc une part essentielle de l’autorité.
  • Le transfert d’agent ne remet pas la clé à l’hôte distant. Il lui donne un chemin pour solliciter une opération privée, ce qui crée une confiance transitive et permet de voler l’usage sans voler la matière secrète.
  • Durée de vie, confirmation et contraintes d’extension réduisent le pouvoir appelable. Le serveur de destination conserve cependant sa propre décision sur la clé, le compte, les facteurs supplémentaires, les canaux et les actions.

Imaginons une clé enfermée dans un module matériel. Son propriétaire ouvre une session vers un serveur de rebond et active le transfert d’agent. Un contrôle superficiel conclut que la clé est en sécurité : aucun fichier privé n’existe sur le serveur de rebond, aucune exportation n’est permise par le module, aucun secret n’a traversé le réseau.

Pourtant, un processus autorisé à joindre le socket transféré peut envoyer une demande de signature. La demande revient jusqu’à l’agent local. Le module calcule la signature, puis le résultat repart vers le processus distant. Si un autre serveur accepte la clé publique pour un compte et valide la signature dans le contexte SSH attendu, l’accès peut réussir. Le coffre n’a pas été ouvert ; sa main a été louée à distance.

C’est la frontière centrale de RFC 9987. Publié en mai 2026 sur le Standards Track, le texte transforme une interface longtemps issue des implémentations en contrat de protocole. Il définit un service piloté par le client : l’agent ne parle jamais spontanément, traite les requêtes et répond dans l’ordre. Il peut refuser des algorithmes, des clés ou des opérations selon son contexte.

Cette sobriété est utile. Elle évite de confondre interopérabilité et politique. Le format indique comment demander une signature ; il ne décide pas qui, dans une organisation, avait le droit de la demander ni ce que le système destinataire devait en faire.

Le socket est une porte de décision

RFC 9987 rappelle que le protocole de l’agent ne fournit ni authentification ni sécurité de transport. Dans le cas habituel, pouvoir lui parler suffit à invoquer une opération privée. Sur Unix, les permissions du socket et l’identité du processus pair peuvent limiter l’accès. Sous Windows, un descripteur de sécurité peut protéger le canal nommé. La variable SSH_AUTH_SOCK permet souvent de découvrir le point de connexion.

Ces mécanismes ne sont pas de simples détails locaux. Ils définissent l’ensemble des demandeurs. Une entreprise qui classe la clé comme « non exportable » mais n’inventorie pas les processus capables de joindre l’agent ne connaît que la moitié de son périmètre de confiance.

Il faut poser deux questions séparées. L’attaquant a-t-il obtenu une copie réutilisable du secret ? A-t-il pu faire exécuter des opérations par le détenteur légitime pendant une période donnée ? La première réponse détermine le risque futur après fermeture de l’agent. La seconde détermine ce qui a pu être authentifié ou signé avant cette fermeture.

La requête de signature rend la séparation concrète. Elle contient le blob de clé publique, les données à signer et des drapeaux d’algorithme. La réponse de succès établit seulement que l’agent a accepté cette opération. Elle n’atteste ni le mandat du processus appelant, ni l’acceptation du compte distant, ni l’ouverture d’un canal, ni l’exécution d’une commande.

Les contraintes ont une vie propre

Le protocole commun propose une contrainte de durée. L’agent supprime la clé après le nombre de secondes demandé depuis son chargement. Cette limite réduit la fenêtre d’appel. Elle n’annule pas une signature déjà produite et ne ferme pas une session que le serveur distant a déjà acceptée.

La contrainte de confirmation exige une décision explicite pour chaque opération privée. Sa valeur dépend de la réalité de l’interface. RFC 9987 ne normalise ni les informations présentées, ni le nom de destination, ni le compte, ni le texte de la question. Une confirmation riche et rare peut créer une décision humaine solide. Une boîte de dialogue répétitive et pauvre en contexte peut devenir un geste automatique.

Les extensions permettent d’ajouter des restrictions propres à une implémentation. Le comportement en cas d’incompréhension est excellent : l’agent doit refuser le chargement au lieu d’ignorer la contrainte inconnue. L’intention restrictive échoue donc fermée. Mais une politique ne devient opérationnelle que si le client et l’agent partagent l’extension et si un test prouve son application.

Le rechargement mérite une surveillance particulière. Lorsqu’une clé existe déjà, une nouvelle demande d’ajout devrait remplacer ses contraintes par celles de la nouvelle demande ; l’agent peut sinon refuser le doublon. Une clé confirmée et temporaire peut donc devenir moins limitée après une transition de configuration. L’état probant est celui lu après chaque ajout, pas celui prévu au début de la journée.

Le verrouillage suspend les opérations sensibles. Il ne rappelle pas les signatures distribuées ni les sessions ouvertes ailleurs. Toute chronologie qui marque « agent verrouillé » comme fin universelle de l’incident confond un changement local avec des effets distants.

Le transfert construit un graphe de confiance

Le transfert d’agent relie l’hôte distant au service local par les canaux de connexion SSH. Le serveur de rebond expose généralement un socket à la session ; les messages qui y entrent reviennent vers l’agent du client. La clé privée n’emprunte jamais le canal.

RFC 9987 qualifie explicitement ce montage de relation de confiance transitive. Il recommande de ne pas l’activer par défaut et de ne pas transférer l’usage vers des hôtes qui ne sont pas pleinement fiables. Sans contrôles supplémentaires sur la visibilité et l’emploi des clés, l’utilisateur ne dispose que d’un choix tout ou rien.

« Pleinement fiable » est une exigence plus large que « l’équipe réseau administre ce serveur ». Elle inclut les privilèges locaux, les extensions, les chaînes de déploiement, les charges hébergées, les bibliothèques et la capacité de détection. Un serveur de rebond réduit parfois l’exposition réseau tout en concentrant un droit d’appel vers de nombreuses identités.

La reconstruction forensique est compliquée par le multiplexage. Plusieurs sessions peuvent partager une connexion SSH et ouvrir des accès concurrents au même agent. Le message agent-connect ne nomme pas le canal de session qui l’a provoqué. Le client peut, sous sa propre politique, accepter une connexion sans demande de session préalable et continuer à l’accepter après la fermeture de la session initiale.

Ces options ne sont pas des défauts en soi. Elles interdisent simplement une attribution paresseuse. Prouver qu’un shell était ouvert et qu’une clé a signé pendant la même minute ne prouve pas que ce shell a demandé l’opération. Il faut relier la connexion externe, la demande de transfert, le canal d’agent, l’empreinte de clé, la requête de signature et la décision du serveur final.

Le serveur garde le dernier mot sur l’authentification

Le protocole d’authentification SSH fournit une limite complémentaire. Dans la méthode par clé publique, la signature couvre l’identifiant de session ainsi qu’une demande précise : nom d’utilisateur, service, méthode, algorithme et clé. Le serveur vérifie séparément que cette clé est autorisée pour le compte et que la signature est correcte. Il peut exiger d’autres facteurs.

Une signature d’agent n’est donc pas un mot de passe universel. Elle se rattache à un échange structuré. Mais un demandeur qui conserve l’accès vivant à l’agent peut construire une nouvelle demande valide pour un autre échange, si la clé y est acceptée. La protection contre la réutilisation d’une signature ne supprime pas le risque de nouvelles signatures.

La chaîne opérationnelle comprend au moins cinq verdicts : clé présente ; point de connexion accessible ; signature acceptée par l’agent ; clé et signature acceptées par le serveur ; session autorisée à produire un effet. Chacun possède un propriétaire, des journaux et une stratégie de refus différents.

Les algorithmes ajoutent un autre plan. Un agent peut savoir utiliser RSA ou Ed25519 ; un client peut demander RSA avec SHA-2 ; un serveur peut refuser cette méthode ; la politique interne peut être plus stricte que tous les trois. Les registres IANA rendent les noms coordonnés. Ils ne certifient ni le déploiement ni la conformité d’un parc réel.

Le dossier de preuve

Au point d’origine, conserver l’identité de l’agent, les permissions et l’identité du pair, l’empreinte de la clé, l’heure de chargement, les contraintes effectives, le verrouillage et le retrait. Pour un jeton, noter aussi le fournisseur chargé et l’isolation de son code.

Au point de transfert, identifier la connexion SSH externe, la décision de confiance envers l’hôte, la demande de transfert, les canaux acceptés et leur durée. Chercher les canaux restés actifs après la fermeture d’une session et les transferts hérités d’une configuration implicite.

Pour chaque opération privée, consigner l’heure, la clé, la méthode, une empreinte sûre du contexte signé et le résultat des contraintes. Une confirmation doit garder assez d’éléments pour expliquer la décision sans répandre les données sensibles.

Enfin, rapprocher ces faits du serveur de destination : compte, clé acceptée, facteurs additionnels, résultat, canaux ouverts et restrictions. Puis observer la conséquence. Une authentification réussie ne prouve pas qu’une commande a réussi ; inversement, une action irréversible ne peut être effacée par le retrait ultérieur de la clé.

La fermeture se prouve elle aussi. Arrêter l’agent, supprimer la clé, fermer les canaux, retirer l’autorisation côté serveur si nécessaire et tester le refus d’une nouvelle tentative. Cette méthode remplace l’étiquette symbolique « clé restée locale » par une chronologie exécutable.