SSH ne se connecte pas

La perte de SSH se présente toujours de la même façon, mais il y a cinq causes, et elles se corrigent différemment. Commencez par le message d'erreur — il réduit immédiatement le champ de recherche. L'essentiel : vous avez toujours accès à la machine via l'onglet « Console » du panneau /hosting/vds/m/<id> ; il fonctionne indépendamment du réseau et des réglages à l'intérieur du système.

Lire l'erreur

Il est utile de regarder les détails : ssh -vvv root@YOUR_ADDRESS montrera à quelle étape cela bloque.

Délai d'attente dépassé

1. Vérifiez l'état de la machine dans l'onglet « Aperçu ». Si les graphiques se sont arrêtés, la machine ne tourne pas — allumez-la ou redémarrez-la depuis le panneau.
2. Assurez-vous que l'adresse est correcte et que la machine est joignable tout court : ping YOUR_ADDRESS.
3. Connectez-vous via la console et vérifiez le filtre :

ss -tulpn | grep sshd
nft list ruleset | head -40      # or iptables -S
ufw status                       # Debian, Ubuntu
firewall-cmd --list-all          # AlmaLinux, CentOS Stream

Le cas classique — vous avez exécuté ufw enable sans autoriser le port 22. Cela se corrige avec une seule commande depuis la console : ufw allow 22/tcp.

1. Vérifiez si fail2ban vous bloque après des tentatives échouées : fail2ban-client status sshd ; pour débannir — fail2ban-client set sshd unbanip YOUR_IP.

Connection refused

Le service n'est pas lancé ou écoute sur un autre port.

systemctl status sshd || systemctl status ssh
journalctl -u sshd -n 50 --no-pager
sshd -t                          # check configuration for errors
systemctl restart sshd

sshd -t sauve la mise le plus souvent : une seule faute de frappe dans /etc/ssh/sshd_config empêche le service de démarrer après un redémarrage. Si vous avez changé le port, connectez-vous avec -p NUMBER et n'oubliez pas de l'autoriser dans le filtre.

Permission denied

Si vous obtenez une erreur de clé, vérifiez sur la machine :

ls -la /root/.ssh
chmod 700 /root/.ssh && chmod 600 /root/.ssh/authorized_keys
grep -E 'PermitRootLogin|PubkeyAuthentication|PasswordAuthentication' /etc/ssh/sshd_config

Si les permissions sont plus strictes que permis, sshd refusera silencieusement. La liste des clés dans le panneau, onglet « Accès », est remplacée entièrement : en ajoutant une nouvelle clé, ne supprimez pas accidentellement une clé qui fonctionne. L'enregistrement de la liste redémarre une machine en cours d'exécution, donc modifiez-la entièrement et une seule fois.

Vous avez oublié le mot de passe root — consultez-le dans l'onglet « Accès » ; il est stocké chiffré et affiché en cliquant sur un bouton. Si vous avez changé le mot de passe à l'intérieur du système, le panneau ne le sait pas : soit vous vous connectez via la console et le changez avec la commande passwd, soit vous cliquez sur « Changer le mot de passe » — le panneau en émettra un nouveau et redémarrera la machine.

Host key verification failed

Après une réinstallation du système, l'empreinte change. Supprimez l'ancienne entrée de votre côté :

ssh-keygen -R YOUR_ADDRESS

S'il n'y a pas eu de réinstallation, ne confirmez pas la nouvelle empreinte à l'aveugle — vérifiez-la via la console : ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub.

Quand rien n'a aidé

Démarrez la machine en mode de récupération : onglet « Accès » → mode de démarrage → disque SystemRescue. La machine démarre depuis l'image, connexion root sans mot de passe, votre disque est visible sous /dev/sda. Montez-le et modifiez la configuration :

mount /dev/sda1 /mnt
nano /mnt/etc/ssh/sshd_config

Revenez ensuite au mode de démarrage normal et redémarrez la machine.

Avant de modifier les réglages SSH, ouvrez une seconde session et gardez-la ouverte. Si la nouvelle configuration vous bloque l'accès, vous corrigerez via l'ancienne connexion sans avoir à recourir à la console.