Atténuation des risques liés au transfert d’agent SSH

Vincent Bernat

ssh-agent est un pro­gramme per­met­tant de conser­ver en mé­moire les clés pri­vées uti­li­sées lors de l’au­then­ti­fi­ca­tion à clé pu­blique de SSH. Lorsque l’agent est pré­sent, ssh lui trans­met les de­mandes de si­gna­ture du ser­veur. L’agent ef­fec­tue les opé­ra­tions sur la clé pri­vée et ren­voie les ré­sul­tats à ssh. Cela est utile si vous conser­vez vos clés pri­vées chif­frées sur le disque et que vous ne sou­hai­tez pas ta­per le mot de passe à chaque connexion. La sé­cu­rité de l’agent est es­sen­tielle : une per­sonne ca­pable de com­mu­ni­quer avec lui peut s’au­then­ti­fier en votre nom sur des ser­veurs distants.

ssh offre éga­le­ment la pos­si­bi­lité de trans­fé­rer l’agent vers un ser­veur dis­tant. De­puis ce­lui-ci, vous pou­vez vous au­then­ti­fier sur un autre ser­veur en uti­li­sant votre agent lo­cal, sans avoir à co­pier votre clé pri­vée sur le ser­veur in­ter­mé­diaire. Comme in­di­qué dans la page du ma­nuel, cela peut être dangereux !

La trans­mis­sion de l’agent doit être ac­ti­vée avec pru­dence. Les uti­li­sa­teurs ayant la pos­si­bi­lité de contour­ner les au­to­ri­sa­tions sur l’hôte dis­tant (pour la chaus­sette UNIX de l’agent) peuvent ac­cé­der à l’agent lo­cal via la connexion trans­fé­rée. Un at­ta­quant ne peut pas ob­te­nir de clé de l’agent, mais il peut ef­fec­tuer des opé­ra­tions sur les clés qui lui per­mettent de s’au­then­ti­fier en uti­li­sant les iden­ti­tés char­gées dans l’agent. Une al­ter­na­tive plus sûre peut être d’uti­li­ser un ser­veur re­lais (voir -J).

Mise à jour (10.2022)

À titre d’exemple, re­gar­dez le rap­port d’in­ci­dent de 2019 de Ma­trix qui in­dique qu’un des vec­teurs d’at­taque ex­ploité était un agent SSH trans­féré sur une ma­chine com­promise.

Comme in­di­qué, une meilleure al­ter­na­tive est d’uti­li­ser la fonc­tion de ser­veur re­lais : la connexion SSH à l’hôte cible est en­cap­su­lée au tra­vers de la connexion SSH au ser­veur re­lais. Voir la page du ma­nuel et ce billet pour plus de détails.

Si vous avez vrai­ment be­soin d’uti­li­ser le trans­fert d’agent SSH, vous pou­vez le sé­cu­ri­ser un peu grâce à un agent dé­dié avec deux ca­rac­té­ris­tiques prin­cipales :

  • il ne dé­tient que la clé pri­vée pour se connec­ter à l’hôte cible ;
  • il re­quiert une confir­ma­tion pour chaque si­gna­ture demandée.

L’alias sui­vant au­tour de la com­mande ssh crée un tel agent éphémère :

alias assh="ssh-agent ssh -o AddKeysToAgent=confirm -o ForwardAgent=yes"

Avec la di­rec­tive -o AddKeysToAgent=​confirm, ssh ajoute la clé pri­vée non chif­frée dans l’agent mais chaque uti­li­sa­tion doit être confir­mée1. Une fois connecté, vous ob­te­nez une in­vite de mot de passe pour chaque de­mande de si­gnature2 :

Invite de confirmation avec l'empreinte de la clé
Invite de la part de l’agent pour confirmer l’utilisation de la clé privée

Mais, en­core une fois, évi­tez d’uti­li­ser le trans­fert d’agent ! ☠️

Mise à jour (04.2020)

Dans une pré­cé­dente ver­sion de cet ar­ticle, assh était im­plé­men­tée à l’aide d’une fonc­tion un peu plus com­plexe. Alexandre Oliva m’a ai­guillé sur la so­lu­tion plus simple ex­po­sée ci-dessus.

Mise à jour (04.2020)

Guar­dian Agent est une al­ter­na­tive en­core plus sûre : elle in­dique et as­sure l’usage (cible et com­mande) de la si­gna­ture de­man­dée. Il existe éga­le­ment un éven­tail de so­lu­tions al­ter­na­tives telles que SSH-Ident, solo-agent ou la so­lu­tion pré­co­ni­sée par Wi­kimedia.

Mise à jour (01.2022)

OpenSSH 8.9 per­met­tra de res­treindre l’usage des clefs trans­fé­rées. Tou­te­fois, la pro­tec­tion of­ferte par ces res­tric­tions reste li­mi­tée. Je conseille de conti­nuer à évi­ter le trans­fert d’agent.