Côté client : ssh -v
ssh -v user@serverUne connexion passe par des étapes dans un ordre fixe. Trouvez la dernière étape qui apparaît dans la sortie, et vous savez où se situe le problème.
1. Lecture de la configuration
debug1: OpenSSH_10.3p1, LibreSSL 3.3.6
debug1: Reading configuration data /Users/you/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_configCela montre la version du client et les fichiers de configuration qu'il a utilisés. Les lignes mentionnant un bloc Host indiquent lesquels correspondent.
2. Connexion
debug1: Connecting to server [203.0.113.10] port 22.
debug1: Connection established.Vérifiez que l'adresse et le port sont ceux que vous attendiez. Si vous n'atteignez jamais Connection established, le problème vient du réseau ou du service, pas de votre connexion :
ssh: connect to host 203.0.113.10 port 22: Connection refusedVoir connection refused, connection timed out et could not resolve hostname.
3. Identification des clés et rencontre avec le serveur
debug1: identity file /Users/you/.ssh/id_ed25519 type 2
debug1: Local version string SSH-2.0-OpenSSH_10.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_10.0p2 Debian-7+deb13u4
debug1: Authenticating to server:22 as 'user'Vérifiez le nom d'utilisateur sur la dernière ligne. Un mauvais utilisateur passe facilement inaperçu et suffit à faire échouer une connexion. identity file ... type -1 signifie que ce fichier n'a pas été trouvé, ce qui est normal pour les types de clés que vous n'avez pas.
4. Accord sur les algorithmes
debug1: kex: algorithm: mlkem768x25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: noneS'il n'y a aucune correspondance, tout s'arrête ici avec un message Unable to negotiate. Voir no matching key exchange.
5. Vérification de l'identité du serveur
debug1: Server host key: ssh-ed25519 SHA256:c+CTM4jkNvBP8UG87Uh12f2SwOsRapfKmGCO8Yv6tc4
debug1: Host 'server' is known and matches the ED25519 host key.
debug1: Found key in /Users/you/.ssh/known_hosts:1Si la clé ne correspond pas, tout s'arrête ici. Voir host key changed.
6. Authentification
C'est ici que se trouvent la plupart des problèmes. Voici à quoi ressemble un échec :
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Will attempt key: /Users/you/.ssh/id_ed25519 ED25519 SHA256:5WGoVhFgmqkQ/7SmXA0cfMDG6u2weqiLGzzf+uY8hCg explicit
debug1: Offering public key: /Users/you/.ssh/id_ed25519 ED25519 SHA256:5WGoVhFgmqkQ/7SmXA0cfMDG6u2weqiLGzzf+uY8hCg explicit
debug1: Authentications that can continue: publickey,password
debug1: No more authentication methods to try.
user@server: Permission denied (publickey,password).Et voici une réussite :
debug1: Offering public key: /Users/you/.ssh/id_ed25519 ED25519 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg explicit
debug1: Server accepts key: /Users/you/.ssh/id_ed25519 ED25519 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg explicit
Authenticated to server ([203.0.113.10]:22) using "publickey".| Ce que vous voyez | Ce que cela signifie |
|---|---|
Aucune ligne Offering public key | Le client n'a trouvé aucune clé à essayer. Vérifiez le chemin, ou utilisez -i. |
| Une autre clé proposée que celle voulue | Définissez IdentityFile et IdentitiesOnly yes pour cet hôte. |
Offering sans Server accepts key | Le serveur n'a pas accepté cette clé. La raison est dans son journal. Voir plus bas. |
Server accepts key, puis un échec | Le serveur accepte la clé, mais le client n'a pas pu signer, par exemple à cause d'une mauvaise phrase secrète. |
Authentications that can continue ne contient pas ce que vous vouliez | Le serveur a désactivé cette méthode. |
Voir Permission denied (publickey) pour les solutions.
7. Après la connexion
debug1: Entering interactive session.
debug1: Sending command: true
debug1: Exit status 0Si la connexion fonctionne et que la session se ferme aussitôt, regardez du côté du shell, des fichiers de démarrage ou d'une commande forcée sur le serveur, pas de SSH lui-même.
-v, -vv et -vvv
Pour une connexion échouée, notre test a affiché 49 lignes avec -v, 95 avec -vv et 133 avec -vvv.
-vvajoute les listes complètes d'algorithmes proposés par chaque côté, souslocal client KEXINIT proposaletpeer server KEXINIT proposal. Utilisez-le pour les problèmes d'algorithmes.-vvvajoute des détails de bas niveau commedebug3: send packet: type 20. Il aide rarement, sauf si vous signalez un bogue.
Pour conserver la sortie dans un fichier, ou ne voir que l'essentiel :
ssh -v -E debug.log user@server
ssh -v user@server 2>&1 | grep -E 'Connecting|Offering|accepts|Authenticat|denied'Voir les vrais réglages : ssh -G
ssh -G server | grep -E '^(user|hostname|port|identityfile|proxyjump) 'Cela affiche ce que le client utiliserait après avoir lu toute sa configuration, sans se connecter. Cela tranche la plupart des débats sur le bloc Host qui s'applique. Avec cette configuration :
Host web*
User deploy
Port 2200
HostName 203.0.113.10
Host *
User other
Port 22ssh -G web1 donne ce qui suit, car la première valeur trouvée l'emporte :
user deploy
hostname 203.0.113.10
port 2200Vous trouverez plus de détails dans le guide sur le fichier de configuration ssh.
Tester sans terminal : ssh -T
-T ne demande aucun terminal. Cela aide à distinguer un problème de connexion d'un problème de session :
ssh -T user@server 'tty; echo TERM=$TERM'not a tty
TERM=dumbLes services qui ne donnent pas de shell, comme les hébergeurs Git, se testent normalement ainsi : ssh -T git@github.com.
Côté serveur
Pour des raisons de sécurité, le client n'entend que Permission denied. La raison va dans le journal du serveur : lisez-le d'abord si vous avez un autre moyen d'y accéder. Voir comment vérifier les tentatives de connexion.
sshd -d sur un autre port
Cela démarre un second serveur qui traite une seule connexion, affiche tout, puis se termine. Votre sshd habituel continue de tourner :
sudo /usr/sbin/sshd -d -p 2200Puis, depuis votre machine :
ssh -p 2200 user@serverUn pare-feu peut devoir autoriser ce port. Le chemin complet est obligatoire : sans lui, vous obtenez sshd requires execution with an absolute path. Voici la partie importante de la sortie quand authorized_keys avait un mauvais mode :
debug1: userauth-request for user user service ssh-connection method publickey [preauth]
debug1: trying public key file /home/user/.ssh/authorized_keys
Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys
Failed publickey for user from 203.0.113.10 port 60932 ssh2: ED25519 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJggEt quand tout fonctionne :
debug1: trying public key file /home/user/.ssh/authorized_keys
debug1: /home/user/.ssh/authorized_keys:1: matching key found: ED25519 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg
Accepted key ED25519 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg found at /home/user/.ssh/authorized_keys:1Utilisez -dd ou -ddd pour en voir plus. Arrêtez-le avec Ctrl+C si personne ne se connecte. Si votre connexion n'apparaît jamais dans cette sortie, quelque chose devant le serveur, comme un pare-feu, la bloque.
sshd -T : les réglages en vigueur
sudo sshd -T | grep -iE '^(port|passwordauthentication|pubkeyauthentication|authorizedkeysfile|permitrootlogin|maxauthtries) 'Cela lit les fichiers de configuration comme le fait le serveur, y compris ceux qu'ils incluent, et affiche les résultats. Il montre les réglages tels que les fichiers les définissent : un serveur pas encore rechargé peut donc encore utiliser d'anciennes valeurs. Pour voir l'effet des blocs Match, décrivez une connexion :
sudo sshd -T -C user=user,host=client.example.com,addr=203.0.113.10 | grep -i passwordauthenticationUtilisez sudo sshd -t pour vérifier seulement la syntaxe. Il n'affiche rien si tout va bien.
Questions
Peut-on partager sans risque la sortie de ssh -v ?
Elle ne contient ni vos mots de passe ni vos clés privées, mais elle montre des noms d'utilisateur, des noms d'hôte, des adresses, des chemins de clés et des empreintes. Relisez-la avant de la publier quelque part en public.
Dois-je toujours utiliser -vvv ?
Non. Commencez par -v. Il répond à la plupart des questions, et les niveaux supplémentaires ajoutent surtout des détails de protocole.