Récupérer l’accès quand SSH ne fonctionne plus

Server Manager communique avec ton serveur uniquement via SSH. Si SSH ne fonctionne plus, Server Manager ne peut pas t’aider — il n’a aucun autre accès à la machine. Mais ton serveur va bien, et tu as d’autres moyens de reprendre la main. Cet article t’aide à diagnostiquer les symptômes les plus courants et te guide dans les procédures de récupération.

Lis ceci avant de paniquer. Aucun des scénarios classiques où SSH ne marche plus ne signifie que tes données ont disparu. Le serveur lui-même fonctionne toujours ; tu ne peux simplement plus t’y connecter depuis l’endroit habituel. Dans le pire des cas, tu réinstalles l’accès SSH via la console web de ton fournisseur cloud — même machine, mêmes disques, mêmes fichiers.

Étape 1 — Lis l’erreur en langage clair

Si tu as essayé de te connecter via Server Manager et que ça a échoué, la boîte de dialogue Connecter affiche déjà un diagnostic en langage clair de ce qui est probablement en cause :

Ce message indique la cause la plus probable. Le tableau ci-dessous associe le message affiché par Server Manager à l’endroit où regarder ensuite.

Étape 2 — Récupère l’accès via la console web de ton fournisseur

Si le diagnostic ci-dessus indique que « quelque chose est cassé sur le serveur lui-même » (la plupart des lignes du tableau), le moyen de reprendre la main est la console web de ton fournisseur cloud — un terminal dans le navigateur qui contourne totalement SSH. Tous les grands fournisseurs en proposent une, avec des noms différents :

Une fois connecté via la console web, tu as un accès shell complet sans passer par SSH — tu peux donc corriger ce qui bloque SSH, puis revenir à Server Manager.

La console web demande le mot de passe local du serveur. C’est le mot de passe au niveau du système d’exploitation pour ton utilisateur sur le serveur lui-même — généralement celui envoyé par e-mail par ton fournisseur, ou celui que tu as défini lors de la configuration initiale. Ce n’est pas ta phrase de passe Server Manager ni le mot de passe de ton compte fournisseur cloud. Si tu n’en as jamais défini et que tu n’as utilisé qu’une clé, exécute passwd <user> via le service de métadonnées de ton fournisseur (DigitalOcean propose « Reset root password » → envoi d’un nouveau mot de passe par e-mail ; AWS permet une réinitialisation via Systems Manager).

Étape 3 — Corrige les causes les plus courantes

Une fois connecté via la console web, vérifie les points suivants :

« J’ai modifié sshd_config et je me suis enfermé dehors »

Le grand classique. Tu as changé quelque chose dans /etc/ssh/sshd_config, redémarré sshd, et maintenant tu ne peux plus rentrer. Récupération :

bashsudo sshd -t                                  # vérifier la syntaxe de la configuration actuelle
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.broken
sudo nano /etc/ssh/sshd_config                # annuler le changement problématique
sudo sshd -t                                  # vérifier à nouveau la syntaxe
sudo systemctl restart sshd                   # redémarrer proprement

Causes fréquentes de verrouillage :

• PermitRootLogin no alors que la connexion se fait en root → réautorise root, ou crée d’abord un utilisateur non-root avec sudo
• PasswordAuthentication no avant d’avoir ajouté la clé dans ~/.ssh/authorized_keys
• Port 2222 (ou un autre port non standard) — le serveur est toujours actif, il écoute simplement ailleurs ; reconnecte-toi sur le nouveau port
• AllowUsers alice qui exclut l’utilisateur avec lequel tu essaies réellement de te connecter

« fail2ban a banni mon IP »

Si tu as saisi le mauvais mot de passe 3 à 5 fois de suite, fail2ban (ou sshguard) bloque souvent ton IP pendant 10 minutes à une heure. Pour vérifier et débannir :

bashsudo fail2ban-client status sshd               # voir les IP bannies
sudo fail2ban-client unban <YOUR-IP>           # débannir la tienne

Ton IP actuelle est celle que curl ifconfig.me affiche depuis ta connexion personnelle (pas depuis le serveur). Pour éviter que ça se reproduise, ajoute-toi dans /etc/fail2ban/jail.local sous ignoreip = une fois que tu as récupéré l’accès.

« ufw / iptables m’a enfermé dehors »

Tu as activé le pare-feu sans autoriser explicitement le port 22 :

bashsudo ufw status                                # voir les règles actuelles
sudo ufw allow 22/tcp                          # autoriser explicitement SSH
sudo ufw reload

Pour iptables directement :

bashsudo iptables -L INPUT -n -v                   # voir ce qui bloque
sudo iptables -I INPUT -p tcp --dport 22 -j ACCEPT
sudo netfilter-persistent save                 # enregistrer (Debian/Ubuntu)

« J’ai supprimé ma propre clé publique de authorized_keys »

Si tu as accidentellement vidé ~/.ssh/authorized_keys (ou appliqué un mauvais chmod), rajoute la clé via la console web :

bashmkdir -p ~/.ssh && chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys                    # coller ta clé publique, enregistrer
chmod 600 ~/.ssh/authorized_keys

La clé publique est le fichier court, sur une seule ligne, généralement situé dans ~/.ssh/id_ed25519.pub (ou id_rsa.pub) sur ton ordinateur. Colle toute la ligne, y compris le préfixe ssh-ed25519 … et le suffixe user@host.

Si tu n’as plus la clé publique d’origine, génère une nouvelle paire de clés sur ton ordinateur :

bashssh-keygen -t ed25519 -C "you@laptop"          # crée ~/.ssh/id_ed25519 + .pub
cat ~/.ssh/id_ed25519.pub                       # coller ceci dans authorized_keys

« Le pare-feu de mon fournisseur a changé tout seul »

Il n’a pas changé tout seul, mais les fournisseurs ajustent parfois leurs politiques par défaut. Ouvre la page Security List / Network Security Group / Firewall Rules de ton fournisseur et vérifie que le port 22 (ou le port sur lequel ton SSH écoute) est toujours autorisé depuis l’internet public (0.0.0.0/0) ou depuis ta plage d’IP spécifique.

Si ton IP a changé (FAI à domicile, déménagement, passage au mobile) et que tu avais limité le pare-feu à ton ancienne IP, la nouvelle IP est bloquée. Élargis temporairement la règle à 0.0.0.0/0, reconnecte-toi, puis resserre-la si tu le souhaites.

Étape 4 — Reconnecte-toi depuis Server Manager

Une fois que SSH fonctionne depuis ton terminal (teste avec ssh -v <user>@<host>), reviens dans Server Manager et clique sur Connecter un serveur. Saisis à nouveau les identifiants, et tu reprends là où tu en étais. L’historique du chat de la session précédente a disparu (les sessions SSH sont uniquement en mémoire par conception), mais tes sites et services sur le serveur sont intacts.

Si tu as enregistré le serveur (avec une phrase de passe de chiffrement Server Manager), sélectionne-le dans le menu déroulant au lieu de tout ressaisir.

Options de dernier recours

Si tu ne peux pas te connecter même via la console web du fournisseur, tu as encore des options :

• Retour à un snapshot — si tu avais pris un snapshot avant le problème (et la plupart des fournisseurs en proposent, parfois automatiquement), restaure ce snapshot. Tu perds les changements effectués depuis, mais tu récupères un système dont tu sais qu’il fonctionne.
• Reconstruction depuis une sauvegarde — si tu as une archive Server Manager .tar.gz (voir Sauvegardes), lance un nouveau serveur, installe Server Manager dessus, puis utilise l’assistant Restaurer depuis une sauvegarde. Même site, nouveau serveur.
• Détacher le disque et le monter sur une autre VM — méthode avancée, mais qui fonctionne chez la plupart des fournisseurs. Arrête la VM cassée, détache son disque de démarrage, attache-le à une VM fonctionnelle comme disque secondaire, monte-le, modifie les fichiers cassés (sshd_config, authorized_keys), démonte-le, rattache-le à la VM d’origine, puis redémarre. La documentation de ton fournisseur détaille les étapes.

Prévention — avant de changer quoi que ce soit lié à SSH

Petite checklist à suivre avant de modifier sshd_config, qui a évité à beaucoup de monde une panique à 2 h du matin :

1. Ouvre une deuxième session SSH avant toute modification — comme ça, si tu te verrouilles hors de la nouvelle session, l’ancienne reste active et tu peux revenir en arrière.
2. **sudo sshd -t** avant de redémarrer — ça détecte la plupart des erreurs de syntaxe.
3. Teste la nouvelle configuration sans la rendre permanente. sudo /usr/sbin/sshd -D -p 2222 -f /etc/ssh/sshd_config.new lance un sshd de test sur le port 2222 avec une configuration de test. Connecte-toi en SSH avec -p 2222 pour vérifier ; si ça marche, remplace ensuite la configuration et redémarre pour de vrai.
4. Prépare l’accès à la console web de ton fournisseur avant de commencer. Ouvre l’onglet, connecte-toi, confirme que la console fonctionne, puis commence les modifications.
5. **Ne lance pas ufw enable via SSH** sans avoir d’abord exécuté sudo ufw allow 22/tcp.

Pour les changements que Server Manager effectue via le chat : Faro attend ton approbation avant chaque commande, et ne proposera rien qui casserait SSH (pas de modification de sshd_config, pas de ufw enable sans règle d’autorisation explicite). Ce sont les sessions manuelles avec nano /etc/ssh/sshd_config qui piègent les gens.

Questions fréquentes

Ai-je perdu quelque chose ? Non — tes fichiers, tes sites et tes bases de données sont exactement comme tu les as laissés. SSH n’est que le canal d’accès ; le serveur lui-même n’a pas été touché.

L’historique du chat a-t-il disparu ? Oui. Les sessions SSH sont uniquement en mémoire — quand la session se termine (de ton côté ou côté serveur), le chat est réinitialisé. En revanche, le travail effectué par le chat sur le serveur reste en place : sites déployés, configurations modifiées, services installés, tout persiste normalement.

Puis-je éviter complètement ce problème ? En grande partie. Le parcours piloté par Server Manager est plus sûr (validation à chaque étape ; pas de modifications de sshd_config). Le risque vient des sessions SSH manuelles où tu modifies toi-même la configuration. Si tu fais tout via Server Manager, le scénario de verrouillage arrive presque jamais.

Mon serveur est chez un fournisseur qui n’est pas dans le tableau ci-dessus. Le principe est universel : la plupart des fournisseurs proposent une forme de console hors bande (VNC, série, shell web). Cherche « console » ou « rescue mode » dans la documentation de ton fournisseur. Si tu as un accès physique (homelab), un écran et un clavier font le même travail.

Server Manager indique « Connexion refusée », mais j’ai utilisé SSH depuis mon terminal il y a 5 minutes. Soit sshd a planté (vérifie via la console de ton fournisseur : systemctl status sshd), soit fail2ban a banni l’IP du VPS de Server Manager (différente de ton IP à domicile — Server Manager tourne dans son propre datacenter, et ton serveur voit cette IP comme source). Mets l’IP de sortie de Server Manager en liste blanche dans le ignoreip = de fail2ban, ou assouplis les paramètres findtime/maxretry.

Ce qui n’est PAS couvert ici

• Récupération au niveau du compte (identifiant Server Manager oublié, mot de passe du compte fournisseur cloud oublié) — ce sont des procédures hors bande : flux de récupération de compte du fournisseur + réinitialisation du mot de passe Server Manager sur la page de connexion.
• Secours d’un disque chiffré (racine chiffrée avec LUKS qui ne se déverrouille pas) — dépend du fournisseur ; consulte sa documentation pour « rescue mode » ou « single-user boot ».
• Clé SSH définitivement perdue sans autre méthode d’accès — à ce stade, la solution pratique est une reconstruction depuis une sauvegarde. Voir Restaurer depuis une sauvegarde et Sauvegardes pour la vue d’ensemble.