SSH modifié, nouvelles connexions refusées : gardez la session

Situation critique : Vous avez modifié SSH. Le terminal actuel fonctionne, mais une nouvelle connexion échoue. Redémarrer tout le serveur est tentant, alors que cette session ouverte est peut-être votre dernier chemin d’administration.

Préserver le chemin de secours

Ne fermez pas l’ancienne session. Si toutes les connexions sont perdues, utilisez une console de gestion autorisée au préalable, telle qu’une console de VM ou une gestion hors bande. Cette note concerne un serveur que vous administrez ; l’entrée sans autorisation ou le contournement de l’authentification n’est pas une récupération.

Distinguer les erreurs par les preuves

Expiration du délai, connexion refusée et échec d’authentification n’ont pas la même cause. Vérifiez le port réel dans la configuration et l’écoute ; supposer le port par défaut peut mener au mauvais service. Ces exemples Ubuntu avec systemd lisent l’état ou valident la configuration :

sudo /usr/sbin/sshd -t
sudo systemctl status ssh.service ssh.socket --no-pager
sudo journalctl -u ssh.service -n 50 --no-pager
sudo ss -ltnp

Un sshd -t réussi et silencieux valide les tests de syntaxe et de clés. Il ne garantit ni l’autorisation du compte voulu ni l’ouverture du chemin dans le pare-feu.

Annuler précisément le dernier changement

Examinez le fichier et la ligne indiqués. Le réglage peut être dans le fichier principal ou dans un fichier inclus de sshd_config.d ; remplacer le principal ne supprime pas nécessairement le nouveau réglage. Restaurez une version saine connue ou le changement précis, validez de nouveau et appliquez seulement après réussite, selon le fonctionnement du service.

Avec l’activation par socket, modifier Port ou ListenAddress suit une procédure distincte. Recharger le service n’est pas une réponse universelle à ces modifications. Ce guide sépare volontairement syntaxe et politique de connexion des changements de port et d’écoute.

Si la syntaxe est correcte mais l’accès refusé, rapprochez compte, clé, permissions des fichiers et règles Match du journal de cette tentative. N’affaiblissez pas globalement l’authentification ou les restrictions pour rouvrir rapidement une entrée.

Le test avant de quitter

Dans un nouveau terminal, établissez une connexion autorisée et exécutez une commande sans effet, par exemple l’affichage du nom d’hôte. Si l’administration nécessite sudo, vérifiez aussi cet accès. Fermez l’ancienne session seulement après réussite du nouveau chemin.

La décision utile : Un fichier valide et un accès utilisable ne sont pas la même chose. Testez les deux avant de fermer l’ancien chemin.

Références techniques: Ubuntu / OpenSSH · OpenBSD / sshd.