Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

ADR-116 — air-agent : agent SSH maison (keystore-backed) d’abord, interop protocole ssh-agent ensuite, agent forwarding opt-in

Statut : Accepté (2026-07-26, décision BDFL). RFC de direction (ADR-015). S’appuie sur ADR-108 (air-keystore

  • air-keysign, motif oracle-safe), ADR-094 (userauth publickey — l’agent fournit les signatures), ADR-091 (motif sans-IO — codec du protocole agent), ADR-089 (SecurityManager — politique de forwarding), ADR-088 (os-free), ADR-095 (packaging), ADR-029 (nommage).

Catégorie : Couche 2 (service) + codec protocole. Vague 2 #4.

Contexte

Un agent SSH détient les clés utilisateur déchiffrées en mémoire et signe à la demande, pour que l’utilisateur ne re-saisisse pas sa phrase de passe à chaque connexion (et pour l’agent forwarding — utiliser ses clés depuis un hôte distant). Air n’en a pas.

Deux voies existent : (a) notre propre agent (keystore-backed) ; (b) parler le protocole ssh-agent d’OpenSSH (via SSH_AUTH_SOCK) pour que ssh/git classiques l’utilisent. L’agent forwarding est la partie la plus sensible (un hôte distant compromis peut utiliser vos clés pendant la session — même classe de risque que la délégation).

Directive BDFL (2026-07-26). Sur le sourcing de l’agent : « (c) les deux à terme, mais (a) d’abord (notre agent, keystore-backed) ; l’interop protocole vient ensuite. L’agent forwarding reste plus sensible → opt-in, plus tard. »

Décision

1. air-agent — service couche 2, cousin d’air-keysign pour les clés utilisateur

Un service air-agent (couche 2, socket Unix, air-socket), qui détient les clés utilisateur (chargées via air-keystore [ADR-108], déchiffrées en mémoire, zeroize au retrait) et signe à la demande. C’est le pendant utilisateur d’air-keysign (qui, lui, sert la clé d’hôte privilégiée) : même motif oracle-safe — restreint les appelants (peer credentials du socket Unix), et sert des signatures, pas les clés privées elles-mêmes. Compilé *-linux-air, packagé ([ADR-095]). Nommage [ADR-029].

2. (a) maison d’abord, (b) interop protocole ensuite, cible (c) les deux

  • (a) D’abord : l’agent maison — API native consommée par air-ssh pour l’auth publickey ([ADR-094]) sans re-saisie.
  • (b) Ensuite : interop du protocole ssh-agent (exposer/consommer SSH_AUTH_SOCK) pour que ssh/git classiques utilisent air-agent, et que air-ssh puisse utiliser un agent OpenSSH existant. Le codec du protocole ssh-agent suit le motif sans-IO ([ADR-091] : cœur pur fuzzable) — l’agent parse des messages externes.
  • Cible (c) : les deux coexistent (agent Air natif + compatibilité écosystème).

3. Agent forwarding = opt-in, plus tard

Le forwarding de l’agent (client qui expose son agent au serveur — auth-agent-req@openssh.com — et serveur qui l’accepte) est désactivé par défaut et opt-in explicite. Il est sensible (un hôte distant compromis peut signer avec vos clés pendant la session) : sa politique relève du SecurityManager ([ADR-089]) ; son câblage (canal auth-agent) dans air-ssh/air-sshd est différé (implémenté quand le besoin est établi, avec les garde-fous).

Conséquences

Positives.

  • Ergonomie : plus de re-saisie de phrase de passe ; base pour l’agent forwarding maîtrisé.
  • Cohérence : même motif oracle-safe qu’air-keysign ([ADR-108]) — l’agent sert des signatures, pas des clés ; keystore-backed.
  • Interop : ssh/git classiques peuvent utiliser air-agent (et inversement) via le protocole standard, codec fuzzé.
  • Risque cadré : forwarding opt-in + politique SecurityManager — on n’ouvre pas la surface sensible par défaut.

Négatives / coûts assumés.

  • Service détenant des secrets en mémoire : cible de valeur ⇒ zeroize, restriction des appelants (peer-cred), pas de dump ; à concevoir avec soin (TCB).
  • Codec ssh-agent = surface externe ⇒ sans-IO + fuzz obligatoires.
  • Forwarding différé : fonctionnalité attendue par certains workflows, volontairement repoussée (sécurité d’abord) — assumé.

Mise en œuvre (référence, hors décision). Incréments : (a) service air-agent maison (socket Unix, signatures via keystore/air-crypto, peer-cred) + intégration air-ssh publickey ; (b) codec protocole ssh-agent (sans-IO, fuzz) + interop SSH_AUTH_SOCK ; (c) agent forwarding opt-in (canal auth-agent, politique SecurityManager) différé. Non engagés par cet ADR.

Alternatives rejetées

Aucune alternative n’a été consignée lors de l’instruction.