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 :
| Commande | La clé peut-elle encore se connecter ? |
|---|---|
passwd -l alice | Oui. Cela ne verrouille que le mot de passe. |
usermod -s /usr/sbin/nologin alice | Plus de shell, mais les tunnels ssh -L fonctionnent encore. |
chage -E 0 alice | Non. 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
sudoersqui la mentionnent. - Les clés ajoutées sous d'autres comptes. Comparez le contenu de chaque fichier
authorized_keysavec 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.