Clé SSH copiée ou agent transféré ? Deux risques différents

Une connexion qui utilise une clé SSH via un VPN ne signifie pas que la clé privée a été remise à l'opérateur du réseau, et cette assurance est plus étroite qu'on ne l'entend. L'authentification par clé publique envoie une clé publique et une signature que le client produit localement. Le transfert d'agent est un autre dispositif avec une autre exposition, et il peut laisser une capacité d'authentification utilisable sur une machine que vous ne contrôlez pas. La réponse que vous devez dépend de laquelle des deux situations s'est réellement produite.

Ce que l'authentification par clé publique envoie

Dans la méthode standard à clé publique, le client propose une clé publique, le serveur décide s'il accepte cette clé, et le client signe un défi avec la clé privée, qui reste dans son fichier ou dans son agent. Ce qui traverse le réseau, c'est la clé publique et la signature qui en résulte. Rien dans cet échange n'exige que le serveur, le tunnel ou quiconque sur le chemin détienne la matière privée.

La spécification d'authentification définit cette preuve, et la clé privée n'est pas un champ de la requête.

C'est un propos sur un protocole, pas une référence de caractère pour chaque point de terminaison impliqué. La vérification de l'identité de l'hôte doit encore rester intacte, car un serveur qui ne peut pas prouver qui il est peut collecter des signatures pour un usage que vous n'aviez pas prévu. Une VM louée, un bastion hérité et un portable exécutant une extension inconnue sont trois questions de confiance distinctes. Gardez-les séparées de la question cryptographique, qui est réellement tranchée.

Ce que le transfert d'agent délègue

Le transfert d'agent ouvre un canal depuis l'hôte distant vers l'agent de votre machine, de sorte que les processus de cet hôte peuvent demander à l'agent de signer sans jamais détenir la clé privée. La clé reste où elle est, la capacité non. Tout ce qui peut atteindre cette socket transférée sur l'hôte distant, pendant la durée de la session, peut demander des opérations d'authentification en tant que l'une des identités chargées. C'est une autorité déléguée, et c'est pourquoi le transfert mérite une politique plus étroite que la remise d'une clé publique.

Un fichier de clé copié est une divulgation. Un agent transféré est une autorisation, et les deux appellent des réponses différentes.

Activez le transfert pour un besoin nommé et des hôtes nommés, et vérifiez ce que le client fait réellement plutôt que ce que la configuration semble dire. Ce sont les réglages effectifs qui comptent, car un bloc d'hôte écrase discrètement une valeur globale par défaut. Le même raisonnement vaut côté serveur, qui peut refuser entièrement le transfert lorsque le déploiement n'en a jamais besoin.

Lisez les preuves avant de choisir une réponse

Si un fichier de clé privée ou une identité de signature équivalente est soupçonné d'avoir été exposé, la réponse est le remplacement et la révocation via le processus de votre organisation, plus le retrait de son acceptation de chaque service qui lui faisait confiance. Supprimer une copie locale n'invalide pas les copies que vous ne voyez pas.

Si la préoccupation est un accès temporaire de l'agent, la réponse est plus étroite : arrêtez la délégation inutile, examinez les sessions et identités concernées, et laissez le responsable de l'incident décider si un remplacement est justifié. Les preuves comptent ici, car l'absence d'exportation observée ne prouve pas qu'aucune authentification n'a été détournée, et un simple changement de chemin n'est pas un diagnostic de clé volée. Notez quel composant était de confiance, si le transfert était activé et ce qui a réellement été observé. Choisissez ensuite la réponse qui correspond à ce dossier plutôt que la plus spectaculaire disponible.

ssh-add -l
ssh -G host.example | grep -i forwardagent

Exécutez-les avant et après un changement pour que la comparaison ait un sens. Une session établie plus tôt conserve la délégation qui lui a été accordée, quoi que disent les réglages maintenant.

Deux contrôles qui ne sont pas interchangeables

Protéger la matière privée, limiter qui peut demander sa signature et vérifier l'identité du pair sont trois contrôles liés, et aucun ne remplace l'autre. Une équipe qui retire le transfert sans vérifier les clés d'hôte a corrigé la moitié d'un problème. Une équipe qui renouvelle une clé parce que la route a changé n'a rien corrigé.

Un point de terminaison compromis est une quatrième question, car un logiciel privilégié sur votre propre machine peut faire bien plus qu'observer des paquets.

Classez l'incident dans ces catégories avant de toucher quoi que ce soit, et donnez à chacune un responsable. Tenez un court registre de ce qui était de confiance, de ce qui a été délégué et de ce qui a été vérifié, car ce registre est ce qui rend la prochaine revue peu coûteuse au lieu d'un autre débat. Si une catégorie est inconnue, écrivez inconnue plutôt que de supposer le cas bénin. La distinction est pratique, non académique : elle décide si vous remplacez un identifiant, révoquez une session ou cessez simplement le transfert.