Atténuation des risques liés au transfert d’agent SSH
Vincent Bernat
ssh-agent est un programme permettant de conserver en mémoire les
clés privées utilisées lors de l’authentification à clé publique de
SSH. Lorsque l’agent est présent, ssh lui transmet les demandes de
signature du serveur. L’agent effectue les opérations sur la clé
privée et renvoie les résultats à ssh. Cela est utile si vous
conservez vos clés privées chiffrées sur le disque et que vous ne
souhaitez pas taper le mot de passe à chaque connexion. La sécurité de
l’agent est essentielle : une personne capable de communiquer avec lui
peut s’authentifier en votre nom sur des serveurs distants.
ssh offre également la possibilité de transférer l’agent vers un
serveur distant. Depuis celui-ci, vous pouvez vous authentifier sur un
autre serveur en utilisant votre agent local, sans avoir à copier
votre clé privée sur le serveur intermédiaire. Comme indiqué dans la
page du manuel, cela peut être dangereux !
La transmission de l’agent doit être activée avec prudence. Les utilisateurs ayant la possibilité de contourner les autorisations sur l’hôte distant (pour la chaussette UNIX de l’agent) peuvent accéder à l’agent local via la connexion transférée. Un attaquant ne peut pas obtenir de clé de l’agent, mais il peut effectuer des opérations sur les clés qui lui permettent de s’authentifier en utilisant les identités chargées dans l’agent. Une alternative plus sûre peut être d’utiliser un serveur relais (voir
-J).
Mise à jour (10.2022)
À titre d’exemple, regardez le rapport d’incident de 2019 de Matrix qui indique qu’un des vecteurs d’attaque exploité était un agent SSH transféré sur une machine compromise.
Comme indiqué, une meilleure alternative est d’utiliser la fonction de serveur relais : la connexion SSH à l’hôte cible est encapsulée au travers de la connexion SSH au serveur relais. Voir la page du manuel et ce billet pour plus de détails.
Si vous avez vraiment besoin d’utiliser le transfert d’agent SSH, vous pouvez le sécuriser un peu grâce à un agent dédié avec deux caractéristiques principales :
- il ne détient que la clé privée pour se connecter à l’hôte cible ;
- il requiert une confirmation pour chaque signature demandée.
L’alias suivant autour de la commande ssh crée un tel agent
éphémère :
alias assh="ssh-agent ssh -o AddKeysToAgent=confirm -o ForwardAgent=yes"
Avec la directive -o AddKeysToAgent=confirm, ssh ajoute la clé
privée non chiffrée dans l’agent mais chaque utilisation doit être
confirmée1. Une fois connecté, vous obtenez une invite de mot
de passe pour chaque demande de signature2 :
Mais, encore une fois, évitez d’utiliser le transfert d’agent ! ☠️
Mise à jour (04.2020)
Dans une précédente version de cet article, assh était implémentée à l’aide d’une
fonction un peu plus complexe. Alexandre Oliva m’a aiguillé sur la
solution plus simple exposée ci-dessus.
Mise à jour (04.2020)
Guardian Agent est une alternative encore plus sûre : elle indique et assure l’usage (cible et commande) de la signature demandée. Il existe également un éventail de solutions alternatives telles que SSH-Ident, solo-agent ou la solution préconisée par Wikimedia.
Mise à jour (01.2022)
OpenSSH 8.9 permettra de restreindre l’usage des clefs transférées. Toutefois, la protection offerte par ces restrictions reste limitée. Je conseille de continuer à éviter le transfert d’agent.