Restaurer un pipeline CI/CD : le guide après une compromission SSH

Restaurer un pipeline CI/CD après une clé SSH compromise peut sembler complexe, mais avec une approche structurée, tout devient clair, reproductible et surtout sécurisé. Dans cet article, je partage les étapes concrètes pour remettre en place un pipeline fonctionnel et sécurisé, basées sur l’expérience vécue aujourd’hui.

Sommaire

• Introduction
• Pourquoi une clé SSH peut être compromise
• Symptômes courants d’un pipeline cassé
• Étapes pour restaurer un pipeline sécurisé
  • Régénérer une nouvelle clé SSH
  • Installer la clé publique sur le serveur
  • Ajouter la clé privée dans GitHub Actions
  • Installer la clé GitHub côté serveur
  • Tester la chaîne CI → Serveur → GitHub
  • Restaurer le pipeline Envoy
• Bonnes pratiques pour éviter un futur incident
• FAQ
• Conclusion

Introduction

Dans un pipeline CI/CD, les clés SSH jouent un rôle fondamental : elles permettent à GitHub Actions de se connecter au serveur, et au serveur de cloner le dépôt pour déployer. Si l’une de ces clés est supprimée, perdue ou compromise, tout le pipeline s’arrête brutalement. Voici un guide simple pour restaurer un pipeline sain et sécurisé.

Pourquoi une clé SSH peut être compromise

Une clé SSH peut devenir inutilisable ou compromise dans plusieurs cas :

• Suppression accidentelle d’un fichier dans ~/.ssh
• Rotation de clés obligatoire pour des raisons de sécurité
• Migration serveur, changement d’utilisateur ou de permissions
• Perte de la clé privée
• Clé exposée dans un pipeline ou un commit

Dans notre cas, le serveur n’avait plus accès à la clé id_github_ed25519 utilisée pour cloner git@github.com:….

Symptômes courants d’un pipeline cassé

• Permission denied (publickey)
• Envoy incapable de cloner le repository GitHub
• GitHub Actions incapable d’exécuter les commandes envoyées au serveur
• Déploiement bloqué sur les tâches createrelease ou git clone

Étapes pour restaurer un pipeline sécurisé

1. Régénérer une nouvelle clé SSH

Sur votre machine locale :

ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_github_ed25519 -C "deploy-key" -N "votre_passphrase"

Cela génère :

• clé privée : id_github_ed25519
• clé publique : id_github_ed25519.pub

2. Installer la clé publique sur le serveur

Copiez la clé publique dans ~/.ssh/authorized_keys pour l’utilisateur app.

3. Ajouter la clé privée dans GitHub Actions

Dans Settings → Secrets → Actions :

• SSH_PRIVATE_KEY_NEW → contenu de la clé privée
• SSH_PASSPHRASE → votre passphrase

4. Installer la clé GitHub côté serveur

Le serveur doit pouvoir cloner votre dépôt privé :

mkdir -p ~/.ssh
nano ~/.ssh/id_github_ed25519
chmod 600 ~/.ssh/id_github_ed25519

Ajoutez ensuite la clé publique dans Deploy Keys GitHub.

5. Tester la chaîne CI → Serveur → GitHub

À tester avant de relancer le pipeline :

ssh -i ~/.ssh/id_github_ed25519 app@your-server 'echo ok'

git ls-remote git@github.com:YOUR_ORG/YOUR_REPO.git

6. Restaurer le pipeline Envoy

Envoy dépend des clés GitHub du serveur et des clés SSH de GitHub Actions. Une fois les deux restaurées, le pipeline fonctionne sans modification du code.

Bonnes pratiques pour éviter un futur incident

• Stocker les clés dans un coffre (Vault, 1Password, Bitwarden)
• Ne jamais commit une clé privée
• Limiter les droits dans authorized_keys
• Régénérer périodiquement les clés
• Documenter le pipeline (clé Actions + clé GitHub serveur)

FAQ

Faut-il remplacer toutes les clés en cas de doute ?
Oui, si une clé peut être compromise, il vaut mieux la remplacer totalement.

La clé doit-elle avoir une passphrase ?
Absolument. Une clé sans passphrase est un risque majeur.

Pourquoi le serveur a besoin d’une clé pour cloner Github ?
Parce que le code source est privé : Envoy ne peut pas déployer sans accès GitHub.

Conclusion

La restauration d’un pipeline CI/CD cassé à cause d’une clé SSH est un excellent rappel : la sécurité et l’automatisation sont profondément liées. En suivant ces étapes, vous pouvez reconstruire rapidement un pipeline fiable, tout en renforçant sa sécurité.