Résoudre une erreur SSH sur votre VPS Ubuntu

Enregistrer une tentative précise

Les commandes client s’exécutent sur votre ordinateur sous Linux, macOS ou WSL. Les vérifications serveur passent par un accès déjà ouvert ou la console authentifiée. Remplacez l’adresse documentaire, le compte, le port et le chemin de clé par vos valeurs.

ssh -G -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10
ssh -v -S none -o ConnectTimeout=10 -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

ssh -G montre les réglages effectifs, y compris les éventuels proxys. La seconde commande désactive le partage de connexion pour cette tentative. Notez l’heure et l’erreur finale. Avant de partager la sortie, masquez adresses, utilisateurs et chemins ; ne transmettez jamais de clé privée.

Choisir la branche qui correspond au résultat

Faites défiler le tableau pour voir toutes les colonnes →

Ces observations limitent les hypothèses sans démontrer une cause unique. Si Connection established apparaît avant le délai, examinez la négociation SSH et les journaux plutôt que de conclure que tous les paquets sont bloqués.

Délai dépassé : suivre le chemin réseau attendu

Comparez l’adresse utilisée par ssh -v à celle de l’instance dans le panneau. Avec un nom de domaine, un ancien DNS ou une autre destination IPv6 peut envoyer ailleurs. Vérifiez si l’accès exige IP publique, VPN ou bastion.

Contrôlez instance en cours d’exécution, route publique, vrai port SSH et source autorisée. Votre IP domestique peut changer alors que la règle /32 reste identique. Vérifiez aussi le pare-feu invité par la console.

Sur Oracle, listes de sécurité, NSG, routes et règles de l’image interviennent ensemble. Installer UFW ou vider iptables n’est pas un diagnostic. Le parcours Oracle décrit le réseau. Un ping sans réponse ne suffit pas à conclure que SSH est inaccessible.

Connexion refusée : vérifier l’écoute

Un refus ne prouve pas que la destination est le bon VPS. Confirmez identité et port, puis exécutez ces contrôles sur le serveur via la console ou l’accès restant :

systemctl status ssh.service ssh.socket --no-pager
sudo ss -lntp
sudo /usr/sbin/sshd -t
sudo journalctl -u ssh.service -u ssh.socket --since '15 minutes ago' --no-pager

Cherchez une écoute sur la bonne adresse et corrélez les journaux à votre tentative. Ubuntu peut utiliser l’activation par socket : ssh.service inactif ne démontre pas un défaut si ssh.socket écoute.

sshd -t vérifie configuration et clés d’hôte sans démarrer le démon. Une réussite silencieuse ne prouve pas l’accès réseau. Corrigez la cause d’une erreur avant un rechargement ; ne redémarrez pas au hasard.

Clé rejetée : utilisateur et identité proposée

Utilisez le compte prévu par l’image ou l’administrateur réellement créé. Dans la sortie détaillée, identifiez l’empreinte offerte. Pour réduire les clés supplémentaires proposées par un agent, essayez localement :

ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

Des IdentityFile de la configuration peuvent encore s’appliquer ; consultez ssh -G. Si la clé locale est illisible ou trop accessible, corrigez ce fichier avant le serveur.

Sur le serveur, vérifiez le compte et les clés publiques autorisées. Adaptez /home/ubuntu au chemin renvoyé par getent :

getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keys

Comparez les empreintes, droits, propriétaires et règles de compte. Un AuthorizedKeysFile différent, des inclusions, des règles Match ou un service de clés du fournisseur peuvent changer le mécanisme. Préservez les clés existantes ; ne désactivez pas StrictModes et n’activez pas les mots de passe pour cacher la cause.

Identité modifiée : vérifier avant de reconnecter

Une reconstruction ou une IP réattribuée peut changer la clé, mais une destination incorrecte ou une interception est aussi possible. Vérifiez l’identifiant de l’instance et la modification prévue dans le panneau authentifié.

Dans la console fiable du système invité, lisez la clé du même algorithme que celui montré par le client. Pour Ed25519 :

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

Comparez la valeur SHA256 à l’avertissement. Il s’agit de la clé du serveur, pas de votre clé utilisateur ni de celle de la passerelle console. Après vérification, sauvegardez known_hosts et remplacez uniquement l’entrée concernée, en tenant compte du port. N’effacez pas tout le fichier et ne désactivez pas la vérification.

Valider la correction dans une nouvelle session

Corrigez l’adresse, le compte, la clé, la règle étroite ou l’erreur de configuration identifiée. Préservez un accès indépendant et validez la configuration SSH avant application. Un changement de port peut concerner la socket, pas seulement le service.

Refaites la tentative sans partage de connexion. Vérifiez le compte atteint et les droits sudo requis. Notez la cause et la modification, puis revenez à la configuration du serveur si elle avait été interrompue.

Questions et réponses