Tu viens de voir un truc louche dans tes logs. Ou pire, un collègue t’écrit sur Slack : « je crois qu’une clé SSH a fuité ». Ça arrive. Copie d’un ~/.ssh dans un zip, poste de dev infecté, CI mal verrouillée, clé privée qui traîne dans un gist, sauvegarde non chiffrée… et d’un coup, ton accès serveur devient une porte entrouverte.
Le réflexe, c’est souvent de paniquer et de « tout couper ». Sauf que dans la vraie vie tu as de la prod, des jobs, une astreinte, et peut être des clients qui attendent.
Donc voilà un plan simple. 60 minutes. Pas parfait, mais réaliste. Tu peux l’appliquer maintenant, puis améliorer ensuite.
Objectif : retirer l’accès de la clé compromise, remettre une nouvelle chaîne de confiance, et limiter la casse. Sans casser la prod.
0 à 5 minutes : confirmer, cadrer, geler
1) Définis le périmètre (vite, pas parfaitement)
- Quel compte ?
root,deploy,ubuntu, un user perso ? - Quels serveurs ? prod, staging, bastion, runners, VPS perso ?
- Quel type de clé ? ed25519, rsa, clé avec passphrase ou non.
- Où est elle utilisée ?
authorized_keys, Git, CI/CD, Ansible, bastion, jump host.
2) Gèle les changements non essentiels
Stop les déploiements automatiques si tu peux. Pas forcément tout arrêter, mais éviter de faire entrer de nouvelles variables pendant que tu rotates.
3) Ouvre un fichier de suivi
Même un bête doc partagé ou un INCIDENT.md. Liste : serveurs, comptes, actions, heure. Dans 2 heures tu te remercieras.
N'oublie pas que dans des situations comme celle-ci il y a souvent une erreur de sécurité unique qui peut aggraver la situation.
5 à 10 minutes : couper l’accès le plus risqué (sans te verrouiller dehors)
Avant de supprimer une clé, assure toi d’avoir un autre accès (console cloud, VPN, autre clé admin, accès bastion). Classique de se lock-out en plein incident.
Option A, rapide et propre : retirer uniquement la clé compromise
Sur chaque machine concernée, édite :
bash sudo -i grep -n "COMMENTAIRE_DE_TA_CLE" /home/deploy/.ssh/authorized_keys nano /home/deploy/.ssh/authorized_keys
Supprime la ligne de la clé compromise. Sauvegarde.
Option B, si tu n’as pas le temps et que l’attaque est en cours : désactiver temporairement l’auth par clés sur un compte
Tu peux verrouiller le compte (attention aux effets de bord) :
bash sudo usermod -L deploy
Ou forcer l’accès via bastion uniquement, si tu as déjà une archi de jump host.
Option C, si tu suspectes un vol massif : couper SSH au réseau public
Firewall express (exemple UFW) :
bash sudo ufw allow from IP_DE_TON_VPN to any port 22 sudo ufw deny 22 sudo ufw enable
Ça peut sauver la prod, mais ça peut aussi casser des automatisations. À utiliser si tu sais ce que tu fais, sinon reste sur A.
10 à 20 minutes : générer et déployer une nouvelle clé (la base, bien faite)
Sur ta machine d’admin (saine), génère une nouvelle clé ed25519 avec passphrase.
bash ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_rotation_incident -C "rotation-incident-YYYYMMDD"
-a 100augmente le coût KDF, c’est plus lent, c’est bien.- Mets une passphrase. Oui, même si tu es pressé.
Ajoute la nouvelle clé publique sur les serveurs à la place, idéalement via un accès déjà existant (console, autre clé, bastion).
bash ssh-copy-id -i ~/.ssh/id_ed25519_rotation_incident.pub deploy@serveur1
Puis teste immédiatement :
bash ssh -i ~/.ssh/id_ed25519_rotation_incident deploy@serveur1 "hostname && whoami"
Si tu as beaucoup de serveurs, fais au moins ceux de prod en premier.
Pour éviter ces situations stressantes liées à la gestion des clés SSH et pour comprendre pourquoi il est peut-être temps de dire adieu à SSH et d'explorer d'autres options plus libératrices, il est essentiel de rester informé des meilleures pratiques en matière de sécurité informatique.
20 à 30 minutes : nettoyer authorized_keys comme un adulte (et poser des garde-fous)
Ce moment est souvent négligé. Pourtant c’est là que tu gagnes en sécurité sans casser grand chose. Pour une sécurité optimale, il est recommandé de suivre cette checklist de hardening SSH.
1) Identifie toutes les clés présentes
Sur chaque serveur :
bash awk '{print NR": "$0}' /home/deploy/.ssh/authorized_keys
Supprime les clés orphelines, inconnues, sans commentaire, ou qui datent d’un autre siècle.
2) Ajoute des restrictions si possible
Tu peux limiter une clé à une IP, ou empêcher le port forwarding. Exemple :
text from="10.0.0.0/24",no-agent-forwarding,no-port-forwarding,no-pty ssh-ed25519 AAAA... commentaire
Ça ne remplace pas une bonne hygiène, mais en incident, c’est un filet.
3) Vérifie les permissions
Le combo qui évite des surprises :
bash chmod 700 /home/deploy/.ssh chmod 600 /home/deploy/.ssh/authorized_keys chown -R deploy:deploy /home/deploy/.ssh
30 à 40 minutes : rotation côté Git, CI/CD, et outils d’automatisation
La clé compromise n’était peut être pas « juste » pour se connecter en SSH. Elle peut aussi donner accès à ton code, à tes pipelines, à tes secrets.
Si la clé sert à Git (GitHub, GitLab, Bitbucket)
- Révoque l’ancienne clé dans l’interface.
- Ajoute la nouvelle clé.
- Cherche aussi les deploy keys sur les repos sensibles.
Si la clé est utilisée par un runner ou un serveur de build
- Mets à jour les variables, les secrets, ou les fichiers montés.
- Vérifie les logs du runner sur la période suspecte.
Si tu utilises Ansible
- Mets à jour l’
ansible.cfgou ton~/.ssh/config. - Vérifie si tu n’as pas une clé copiée dans le repo (oui, ça arrive…).
Si tu utilises un bastion
- Rotation d’abord sur le bastion, puis sur les cibles.
- Désactive l’agent forwarding si ce n’est pas vital.
40 à 50 minutes : vérifier qu’il n’y a pas déjà un accès persistant
Rotation de clés, c’est bien. Mais si un attaquant a déjà posé une backdoor, tu peux tourner les clés toute la nuit, ça ne servira pas à grand chose.
Sans partir sur une forensic complète, fais au minimum :
1) Cherche des utilisateurs suspects bash cut -d: -f1 /etc/passwd sudo awk -F: '$3==0 {print $1}' /etc/passwd
2) Vérifie les authorized_keys de tous les comptes à risque bash sudo find /home -maxdepth 2 -name authorized_keys -print -exec wc -l {} ; sudo ls -la /root/.ssh 2>/dev/null
3) Regarde les connexions SSH récentes Selon distro : bash sudo journalctl -u ssh --since "24 hours ago" | tail -n 200
sudo grep "sshd" /var/log/auth.log | tail -n 200
Tu cherches : IP inconnues, horaires bizarres, connexions réussies sur des comptes sensibles.
4) Processus et crons bash ps auxf | head -n 50 sudo crontab -l sudo ls -la /etc/cron.* /var/spool/cron 2>/dev/null
Ce n’est pas une enquête complète, mais ça attrape souvent les erreurs grossières.
50 à 60 minutes : durcir SSH rapidement (sans refaire toute l’infra)
Tu veux réduire la probabilité que ça se reproduise. Là, on vise des modifications simples, testables, revertables.
Dans /etc/ssh/sshd_config (ou un fichier inclus), vérifie :
text PasswordAuthentication no PermitRootLogin no PubkeyAuthentication yes MaxAuthTries 3 AllowUsers deploy admin
Ensuite :
bash sudo sshd -t sudo systemctl reload ssh
Attention : ne fais pas ça si tu n’as pas confirmé que l’accès par clé fonctionne, sinon tu peux te bloquer. Oui, je me répète. C’est volontaire.
Images utiles à insérer (pour ton article et pour tes checklists)
Tu peux placer ces visuels dans l’article pour aérer, surtout si tu le publies sur monblog-sa-abasse.blogspot.com et que tu veux un rendu plus « guide pratique ».
Schéma rapide du plan 60 minutes
Exemple de terminal et audit express
Contexte sécurité et accès
Petit mémo : commandes « panique maîtrisée »
À garder sous la main.
bash
cat ~/.ssh/authorized_keys
grep -n "rotation-incident" ~/.ssh/authorized_keys
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_new -C "rotation-incident"
sudo sshd -t
sudo journalctl -u ssh --since "2 hours ago" sudo tail -n 200 /var/log/auth.log
Après l’heure : ce que je ferais ensuite (vraiment)
Une fois l’incendie éteint, tu peux passer en mode propre.
- Mettre en place un inventaire des clés et une politique de rotation.
- Passer par un bastion obligatoire, ou mieux, du SSH via VPN ou Zero Trust.
- Utiliser des certificats SSH (OpenSSH CA) au lieu de clés statiques partout.
- Ajouter du MFA côté accès admin quand c’est possible (selon stack).
- Monitorer les connexions SSH et alerter (fail2ban, SIEM, Loki, etc).
- Interdire les clés sans passphrase sur les postes, et chiffrer les backups.
Je publierai probablement une check-list plus « long terme » sur Le Blog Tech Pro de Samyn-Antoy ABASSE (monblog-sa-abasse.blogspot.com), parce que c’est typiquement le genre de routine SysAdmin qui te sauve une semaine de stress. Si tu veux, tu peux aussi y piocher mes articles Linux et productivité pour mettre ça en process, pas juste en réaction. Par exemple, voici 25 commandes Linux qui sauvent en situation critique.
Conclusion
Une clé SSH compromise, ce n’est pas une honte. C’est un test brutal de tes habitudes et de ton système.
En 60 minutes, tu peux faire l’essentiel : supprimer l’accès compromis, remettre une nouvelle clé, sécuriser les points d’entrée évidents, et vérifier qu’il n’y a pas un invité déjà installé.
Et ensuite seulement, tu respires. Tu écris le post-mortem. Tu automatises la rotation. Et tu t’épargnes le prochain incident, ou au moins tu le rends beaucoup moins dramatique.
Questions fréquemment posées
Que faire immédiatement après avoir détecté une fuite de clé SSH ?
Il faut d'abord confirmer l'incident, définir rapidement le périmètre affecté (compte, serveurs, type de clé), geler les changements non essentiels comme les déploiements automatiques, et ouvrir un fichier de suivi pour documenter toutes les actions et observations.
Comment retirer l'accès d'une clé SSH compromise sans se verrouiller hors du système ?
Avant toute suppression, assurez-vous d'avoir un autre accès valide (console cloud, VPN, autre clé admin). Ensuite, retirez uniquement la clé compromise des fichiers authorized_keys sur chaque serveur concerné. En cas d'urgence, vous pouvez temporairement verrouiller le compte ou restreindre l'accès SSH au réseau privé via un firewall.
Pourquoi est-il recommandé de générer une nouvelle clé SSH ed25519 avec passphrase après un incident ?
La génération d'une nouvelle clé ed25519 avec une passphrase renforce la sécurité grâce à un algorithme moderne et une protection supplémentaire. L'option '-a 100' augmente le coût du dérivatif de clé pour ralentir les attaques par force brute. Cela permet de rétablir une chaîne de confiance sécurisée après la compromission.
Quels sont les risques de ne pas agir rapidement lors d'une fuite de clé SSH ?
Ne pas agir rapidement peut entraîner un accès non autorisé aux serveurs, compromettant la production, exposant des données sensibles et facilitant des attaques plus larges. Cela peut aussi causer des interruptions de service et compromettre la confiance des clients.
Comment limiter l'impact sur la production tout en gérant une fuite de clé SSH ?
Le plan proposé vise à agir en 60 minutes sans casser la production : définir le périmètre, geler les changements non essentiels pour éviter d'introduire de nouvelles vulnérabilités, retirer rapidement la clé compromise tout en conservant l'accès nécessaire pour intervenir, puis déployer une nouvelle clé sécurisée.
Pourquoi est-il important d'ouvrir un fichier de suivi lors d'un incident lié à une fuite de clé SSH ?
Un fichier de suivi documente toutes les actions entreprises, les serveurs concernés, les comptes affectés et les heures des interventions. Cela facilite la coordination entre équipes, évite les erreurs répétées et permet un retour d'expérience efficace après l'incident.
0 Commentaires