Redirection d'agent SSH ou copie de clé : ce qui fuit réellement

Deux événements différents portent le nom de clé SSH compromise, et ils appellent des réponses différentes. L'authentification par clé publique envoie une clé publique et une signature produite avec la clé privée, si bien que la clé privée n'est jamais un champ de la requête. La redirection d'agent expose autre chose, car un hôte distant qui atteint votre agent redirigé peut lui demander de signer sans jamais détenir la clé. Traiter les deux comme un seul événement mène soit à une rotation inutile, soit à une délégation qui reste active.

La connexion par clé publique transmet une signature, pas la clé

L'échange d'authentification transporte la clé publique de l'utilisateur et une signature portant sur les données de session. Le serveur vérifie cette signature avec la clé à laquelle il fait déjà confiance, c'est pourquoi la moitié privée peut rester sur le client à travers un réseau non fiable. Un opérateur VPN qui observe le tunnel voit de toute façon une session SSH chiffrée.

Cela décrit le protocole, pas la fiabilité de chaque extrémité du chemin. Gardez intacte la vérification de l'identité de l'hôte, car un client qui accepte n'importe quelle clé d'hôte a abandonné un contrôle différent de celui dont nous parlons. Une session capturée et une clé capturée sont deux constats distincts, et un seul des deux est une perte d'identifiants. Gardez les deux dans des phrases séparées du rapport.

ssh-keygen -lf ~/.ssh/id_ed25519.pub
ssh -o StrictHostKeyChecking=yes [email protected]

La première commande affiche l'empreinte publique pour que vous la compariez à ce que le serveur énumère. La seconde rend explicite le contrôle de la clé d'hôte au lieu de se fier à une valeur par défaut que personne n'a lue. Exécutez les deux avant de modifier quoi que ce soit aux clés, afin que la base de référence soit documentée.

Rediriger un agent délègue la capacité de signer

Quand la redirection est activée, une socket apparaît sur l'hôte distant et l'agent local répond aux requêtes qui y arrivent. Quiconque peut utiliser cette socket pendant la session peut s'authentifier comme vous auprès des hôtes qui acceptent les identités chargées. Aucune clé privée ne traverse le réseau pour que cela fonctionne.

L'exposition, c'est la capacité, pas le fichier. C'est pourquoi la redirection relève d'une tâche nommée et d'un hôte nommé, et non de chaque connexion qu'un ordinateur portable établit. Un hôte de rebond qui relaie la connexion sans agent redirigé supprime généralement le besoin tout à fait.

ssh-add -l
ssh -o ForwardAgent=no [email protected]
ssh -J [email protected] [email protected]

La première liste les identités que l'agent détient actuellement, ce qu'il vaut la peine de savoir avant de confier sa socket à une autre machine. La seconde se connecte sans délégation. La troisième montre le schéma de l'hôte de rebond qui remplace souvent la redirection entièrement.

Choisissez la réponse d'après les preuves dont vous disposez

Une identité de signature que l'on croit exposée exige le processus de remplacement et de révocation, et le retrait de son acceptation auprès des services qui lui faisaient confiance. Supprimer la copie sur votre ordinateur portable laisse toutes les autres copies intactes. Commencez par les services, puis nettoyez les clients.

Un problème de délégation temporaire est plus étroit. Mettez fin à la redirection qui n'était pas nécessaire, et examinez avec le responsable de l'incident les sessions et identités qu'elle couvrait. Le remplacement de la clé peut suivre, mais ce sont les preuves qui en décident, pas l'inquiétude.

Aucune exportation observée ne prouve qu'une chose : que le mécanisme que vous craigniez ne s'est pas produit. Cela ne dit rien de ce qu'un hôte à l'autre bout de cette socket aurait pu faire d'autre.

Gardez les contrôles distincts dans le rapport

Protégez le matériel privé, limitez qui peut lui demander de signer, maintenez l'identité de la contrepartie vérifiée. Ce sont trois contrôles qui se renforcent mutuellement, et aucun ne remplace l'autre lorsque vous expliquez ce qui s'est passé.

Un ordinateur portable compromis ou une application privilégiée dessus est un troisième cas, avec un rayon d'impact bien plus large. Changer la route VPN ne le résout pas et ne rétablit pas la confiance dans une clé qui a peut-être été lue sur le disque.

Notez quel composant était de confiance, si la redirection était active et ce qui a réellement été observé. C'est ce compte rendu qui rend la décision suivante défendable, au lieu d'une conjecture sur ce que signifie une fuite.