SSH : dépannage

Méthode et erreurs fréquentes pour comprendre pourquoi une connexion SSH échoue. Les exemples utilisent des noms génériques.

Méthode

Côté client : relancer avec ssh -v (ou -vv, -vvv) pour voir où l’échange s’arrête.
Côté serveur : lire sudo journalctl -u ssh -f pendant la tentative de connexion.
Réseau : vérifier le port et le pare-feu (nc, ss, UFW).
Vérifier la configuration effective : sudo sshd -T, ssh -G alias.

Voir ce que fait le client : `ssh -v`

ssh -v deploy@serveur.exemple.com

Lignes utiles du résultat :

Ligne	Signification
`Connecting to … port 22`	Adresse et port visés
`kex: algorithm: …`	Algorithme d’échange de clés négocié
`Offering public key: …`	Clé proposée au serveur
`Server accepts key`	Le serveur reconnaît la clé
`Authenticated to … using "publickey"`	Succès
`Authentications that can continue: publickey,password`	Méthodes que le serveur propose encore

Voir ce que voit le serveur : les journaux

sudo journalctl -u ssh -f                                   # en direct
sudo journalctl -u ssh --since "10 minutes ago" --no-pager
sudo journalctl -u ssh | grep -iE "failed|refused|invalid|error"

Message du serveur	Cause
`Authentication refused: bad ownership or modes for directory /home/deploy`	Dossier personnel modifiable par d’autres : `chmod go-w ~`
`Authentication refused: bad ownership or modes for file /home/deploy/.ssh/authorized_keys`	`chmod 600 ~/.ssh/authorized_keys`, `chmod 700 ~/.ssh`, propriétaire correct
`Failed publickey for deploy`	Clé absente de `authorized_keys`, ou mauvaise clé proposée
`User deploy not allowed because not listed in AllowUsers`	`AllowUsers` ne contient pas ce compte
`Invalid user admin from …`	Tentative sur un compte inexistant (scan)
`maximum authentication attempts exceeded`	Trop d’échecs sur une connexion (`MaxAuthTries`)
`Connection closed by authenticating user … [preauth]`	Le client a abandonné pendant l’authentification

Erreurs courantes côté client

Message	Cause probable et solution
`Connection refused`	Rien n’écoute sur ce port : `systemctl status ssh.socket`, mauvais port (`-p`), pare-feu local
`Connection timed out`	Paquets ignorés : adresse erronée, pare-feu (UFW ou hébergeur), serveur éteint
`Permission denied (publickey)`	Clé non autorisée ou droits incorrects (voir ci-dessus et Clés SSH)
`Permission denied (publickey,password)`	Mot de passe accepté mais incorrect, ou clé refusée
`Too many authentication failures`	L’agent propose trop de clés : `IdentitiesOnly yes` et `IdentityFile`
`Host key verification failed`	La clé du serveur a changé ou est inconnue (section suivante)
`Could not resolve hostname`	DNS ou nom mal saisi
`Connection reset by peer`, `kex_exchange_identification: read: Connection reset`	Le serveur coupe la connexion : pare-feu, `PerSourcePenalties`, Fail2ban, trop de connexions
`no matching host key type found` / `no matching key exchange method found`	Client et serveur n’ont aucun algorithme commun (très ancien client ou serveur)
`Bad owner or permissions on ~/.ssh/config`	`chmod 600 ~/.ssh/config`

Avertissement de clé d’hôte modifiée

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

SSH a détecté que la clé du serveur n’est plus celle enregistrée. Deux explications :

Légitime : le serveur a été réinstallé ou son adresse IP a été réattribuée à une autre machine.
Attaque : quelqu’un se fait passer pour le serveur (« homme du milieu »).

Procédure :

# 1. Vérifier l'empreinte réelle depuis une autre voie (console de l'hébergeur) :
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
# 2. Si elle correspond à celle annoncée par la connexion, supprimer l'ancienne entrée :
ssh-keygen -R serveur.exemple.com
ssh-keygen -R 203.0.113.10
# 3. Se reconnecter et vérifier l'empreinte proposée.

Droits et propriétaires : la cause la plus fréquente

ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

Élément	Attendu
`~` (dossier personnel)	Non modifiable par le groupe ni les autres (`755` ou `750`)
`~/.ssh`	`700`, propriétaire l’utilisateur
`~/.ssh/authorized_keys`	`600`, propriétaire l’utilisateur
Clé privée côté client	`600`

chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$USER:$USER" ~/.ssh

Tester côté serveur sans toucher au service : `sshd -d`

sudo /usr/sbin/sshd -d -p 2222          # serveur de test en premier plan, un seul client, journal détaillé
ssh -p 2222 deploy@serveur.exemple.com   # depuis un autre terminal

Il s’arrête à la fin de la connexion. Penser à autoriser le port 2222 (UFW) pour le test, puis à le refermer.

Vérifier le réseau et le pare-feu

nc -vz serveur.exemple.com 22              # le port répond-il ?
sudo ss -tlnp | grep -E ':22\b|ssh'        # (sur le serveur) qui écoute ?
sudo ufw status verbose                    # règles du pare-feu
sudo ufw allow OpenSSH

Connexions refusées temporairement : `PerSourcePenalties`, Fail2ban

Un serveur peut refuser temporairement votre adresse après des échecs répétés :

OpenSSH 10 (Ubuntu 26.04) applique PerSourcePenalties : sudo sshd -T | grep persourcepenalties. Le journal du serveur l’indique.
Fail2ban bannit les adresses fautives : sudo fail2ban-client status sshd puis sudo fail2ban-client set sshd unbanip 203.0.113.5.

Attendre l’expiration, ou débloquer depuis une autre adresse ou la console.

Récupérer l’accès après un verrouillage

Si la connexion par SSH est devenue impossible (mauvaise configuration, pare-feu) :

Ouvrir la console de l’hébergeur (accès VNC, série ou « rescue ») et se connecter en local.
Corriger : sudo rm /etc/ssh/sshd_config.d/00-durcissement.conf, ou sudo ufw allow OpenSSH.
sudo sshd -t && sudo systemctl reload ssh.
Tester une nouvelle connexion avant de fermer la console.

Pour limiter le risque : toujours garder une session ouverte pendant les modifications (voir Durcissement du serveur).

Diagnostiquer la lenteur de connexion

time ssh -o BatchMode=yes monserveur true
ssh -vvv monserveur 2>&1 | grep -iE "debug1: (Connecting|Authenticat|SSH2_MSG)"

Causes fréquentes : résolution DNS inverse du serveur (UseDNS), authentification GSSAPI (GSSAPIAuthentication no dans le client), serveur surchargé.

Dépannage des tunnels

Voir Tunnels et rebonds (erreurs bind, connect failed, administratively prohibited).

Ubuntu 24.04 et 26.04 : différences à connaître

Pour aller plus loin

Manuel : man ssh, man sshd
Retour : Installation