Comment révoquer une clé SSH quand quelqu'un quitte l'équipe

Relevez l'empreinte de la clé, cherchez-la dans chaque fichier authorized_keys de chaque serveur, et supprimez ces lignes. Pour bloquer la clé partout où elle pourrait se cacher, ajoutez-la aussi au fichier désigné par RevokedKeys dans sshd_config. Les sessions déjà ouvertes restent ouvertes : fermez-les aussi. Changez ensuite tout secret partagé que la personne connaissait, car supprimer une clé ne les couvre pas.

Mis à jour le . La recherche par empreinte, la suppression, RevokedKeys avec un fichier simple et avec une KRL, la révocation et l'expiration de certificats, ainsi que l'effet de passwd -l, nologin et chage ont tous été exécutés avec OpenSSH 10.0 sur Debian 13, dans un conteneur jetable.

Retrouver la clé par son empreinte

Un commentaire comme alice@laptop peut être modifié et ne prouve rien : cherchez donc par empreinte. Si vous avez la clé publique :

ssh-keygen -lf alice.pub
256 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg alice@laptop (ED25519)

Si vous ne l'avez pas, le journal du serveur indique quelle clé chaque connexion a utilisée :

Accepted publickey for deploy from 203.0.113.10 port 33998 ssh2: ED25519 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg

Voir comment vérifier les connexions SSH pour savoir où se trouve ce journal.

Chercher sur un serveur

Exécutez ceci en root, car chaque ~/.ssh est privé à son propriétaire :

sudo bash -c '
FP="SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg"
for f in /root/.ssh/authorized_keys* /home/*/.ssh/authorized_keys*; do
  [ -f "$f" ] && ssh-keygen -lf "$f" | grep -F "$FP" && echo "  found in $f"
done'

Vérifiez les comptes de service dont le dossier personnel est ailleurs, ainsi qu'un éventuel AuthorizedKeysFile différent :

sudo sshd -T | grep -i authorizedkeysfile
getent passwd | cut -d: -f1,6

Chercher sur tous les serveurs

Enregistrez la recherche ci-dessus sous forme de script sur chaque serveur, ou lancez-la par une boucle depuis votre machine. La liste des hôtes est à vous de la fournir, et sudo ne doit pas demander de mot de passe ici :

while read -r host; do
  echo "== $host"
  ssh -n "$host" sudo /usr/local/bin/find-ssh-key
done < hosts.txt

N'oubliez pas les machines qui ne sont pas des serveurs au sens habituel : hébergement Git, équipements réseau, hôtes de rebond, runners CI et cibles de sauvegarde.

Le rôle de -n dans cette boucle est expliqué dans comment exécuter une commande par SSH.

Supprimer la clé

Comparez la clé elle-même, pas le commentaire, et gardez une sauvegarde :

KEY=$(cut -d' ' -f2 alice.pub)
f=/home/deploy/.ssh/authorized_keys
sudo cp -p "$f" "$f.bak"
sudo grep -vF "$KEY" "$f.bak" | sudo tee "$f" > /dev/null

Supprimez la sauvegarde une fois que vous avez vérifié que les autres peuvent toujours se connecter. La même clé peut apparaître sur plusieurs lignes, et cette commande les supprime toutes.

La bloquer avec RevokedKeys

Supprimer les lignes règle ce que vous avez trouvé. RevokedKeys bloque en plus la clé sur tout compte où vous ne l'avez pas trouvée, ou où elle serait remise. La forme la plus simple est un fichier de clés publiques :

sudo cp alice.pub /etc/ssh/revoked_keys
sudo chmod 644 /etc/ssh/revoked_keys
# /etc/ssh/sshd_config.d/10-revoked.conf
RevokedKeys /etc/ssh/revoked_keys
sudo sshd -t && sudo systemctl reload ssh

Le service s'appelle sshd sur Red Hat et Fedora. Une connexion avec cette clé échoue désormais, et le journal indique :

Authentication key ED25519 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg revoked by file /etc/ssh/revoked_keys

Créez le fichier avant d'ajouter le réglage. S'il est absent ou illisible, sshd refuse les connexions par clé publique pour tous les utilisateurs. Dans notre essai, le journal disait Error checking authentication key ... in revoked keys file. Un fichier vide convient.

Une KRL pour de nombreuses clés

Une Key Revocation List (KRL) est une version binaire compacte du même fichier, et le réglage est le même. Créez-en une et complétez-la avec -u. Sans -u, elle remplace le contenu existant :

sudo ssh-keygen -k -f /etc/ssh/revoked_keys alice.pub
sudo ssh-keygen -k -u -f /etc/ssh/revoked_keys bob.pub

Vérifiez une clé par rapport à elle :

ssh-keygen -Q -f /etc/ssh/revoked_keys alice.pub
alice.pub (alice@laptop): REVOKED

Une clé absente de la liste affiche ok. Le code de sortie est 1 quand une clé est révoquée et 0 sinon, ce qui est pratique dans les scripts. Vous pouvez lister le contenu d'une KRL avec ssh-keygen -Q -l -f /etc/ssh/revoked_keys.

Fermer les sessions déjà ouvertes

Une clé révoquée n'empêche que les nouvelles connexions. Dans notre essai, une session ouverte avant la suppression de la clé a continué de tourner et s'est terminée normalement. Cherchez les sessions ouvertes avec who et, s'il s'agit du compte personnel de cette personne, fermez-les :

sudo pkill -KILL -u alice

Cette commande tue tout ce que ce compte exécute : ne l'utilisez pas sur un compte partagé sans avoir regardé d'abord.

Fermer le compte

Certaines commandes courantes en font moins que prévu. Nous avons testé chacune avec une clé fonctionnelle :

CommandeLa clé peut-elle encore se connecter ?
passwd -l aliceOui. Cela ne verrouille que le mot de passe.
usermod -s /usr/sbin/nologin alicePlus de shell, mais les tunnels ssh -L fonctionnent encore.
chage -E 0 aliceNon. Le journal indique Access denied for user alice by PAM account configuration.

Utilisez chage -E 0 pour bloquer le compte immédiatement, et supprimez-le plus tard avec userdel quand vous saurez que rien n'en dépend.

Tout le reste que la personne connaissait

Si la personne avait accès à un compte partagé ou au root d'un serveur, une clé n'est peut-être qu'une partie du problème. Vérifiez :

  • Les comptes partagés : remplacez leurs clés et leurs mots de passe.
  • Les clés privées qu'elle pouvait lire, comme les clés de déploiement : remplacez-les et révoquez les anciennes.
  • Les crontabs et les fichiers sudoers qui la mentionnent.
  • Les clés ajoutées sous d'autres comptes. Comparez le contenu de chaque fichier authorized_keys avec ce que vous vous attendez à y trouver.

Faciliter la suite : des certificats de courte durée

Avec les certificats SSH, il n'y a pas de liste de clés sur chaque serveur. Le serveur fait confiance à une autorité de certification, et chaque certificat expire de lui-même. La commande suivante signe une clé pour huit heures, pour le compte deploy :

ssh-keygen -s user_ca -I alice@example.com -n deploy -V +8h -z 1001 alice.pub

Quand quelqu'un part, cessez de signer pour lui. Le dernier certificat cesse de fonctionner tout seul, et le journal indique Certificate invalid: expired. Pour couper un certificat avant, révoquez-le par identité ou par numéro de série. Écrivez un petit fichier nommé spec :

id: alice@example.com
serial: 1001
sudo ssh-keygen -k -u -f /etc/ssh/revoked_keys -s user_ca.pub spec

Voir les certificats SSH expliqués pour la mise en place.

Questions

Supprimer un utilisateur Linux retire-t-il son accès SSH ?

Supprimer le compte avec userdel bloque les connexions à ce compte. Verrouiller seulement le mot de passe avec passwd -l ne suffit pas : une clé se connecte encore. Sa clé peut aussi se trouver dans d'autres comptes, donc cherchez par empreinte.

Les sessions SSH ouvertes se ferment-elles quand on retire une clé ?

Non. Retirer ou révoquer une clé n'arrête que les nouvelles connexions. Fermez les sessions déjà ouvertes, par exemple avec pkill sur le compte de la personne.

Qu'est-ce qu'une KRL OpenSSH ?

Une Key Revocation List : un fichier binaire compact de clés et de certificats révoqués, créé avec ssh-keygen -k et désigné par RevokedKeys dans sshd_config.

Sources

Autres guides : Sécuriser un serveur

Tous les guides