Le ping fonctionne mais SSH échoue via le VPN : quelle étape a cassé ?
Une seule tentative détaillée sépare l’accessibilité TCP, le transport SSH, l’identité de l’hôte, la connexion de l’utilisateur et l’autorisation de session, pour que vous cessiez de deviner sur le tunnel.
Les réponses au ping et une connexion SSH refusée peuvent être vraies en même temps, et le couple n’incrimine pas le tunnel. Les réponses d’écho et une connexion TCP au port 22 sont des tests différents avec des sélecteurs différents, des politiques différentes et souvent des destinations différentes. Capturez une tentative SSH délibérée, puis nommez la dernière étape qu’elle a atteinte. Cet unique artefact remplace une douzaine de changements de configuration spéculatifs.
Capturez une tentative, pas une séance de tâtonnements
Lancez le client une fois avec des diagnostics détaillés, le partage de connexion désactivé et un délai de connexion borné. Désactiver le partage compte, car une connexion maître déjà authentifiée répondrait sinon à la place de la nouvelle tentative et masquerait la panne que vous traquez.
ssh -4 -vv -o ControlPath=none -o ConnectTimeout=10 [email protected]Conservez la destination, la famille d’adresses, l’horodatage et la dernière erreur non secrète. L’indicateur IPv4 signifie aussi que cette tentative ne dit rien d’un chemin IPv6 vers le même nom, alors ne généralisez pas à partir d’elle. Notez d’où la tentative a été faite. Une vérification sur la passerelle VPN n’est pas le même point de vue qu’un portable derrière elle, et la plupart des contradictions dans ces tickets viennent de mélanger les deux.
Étapes un et deux : TCP avant SSH
La première frontière est l’accessibilité de la socket : une adresse, un port et une route que le paquet suit réellement. Si la connexion TCP n’aboutit jamais, rien au-dessus n’existe encore, et les clés d’hôte et les comptes sont sans pertinence.
nc -vz 10.90.4.20 22
ip route get 10.90.4.20
tcpdump -ni any 'host 10.90.4.20 and port 22'Corrélez la capture avec la tentative du client. Un SYN qui part sans rien revenir pointe vers un filtrage, des sélecteurs ou une route manquante de l’autre côté ; une réponse avec réinitialisation pointe vers quelque chose qui refuse activement au lieu de jeter. La deuxième frontière est l’échange du protocole SSH lui-même. Une connexion TCP qui aboutit puis cale a dépassé l’accessibilité et est entrée en négociation, en réponse du serveur ou en traitement de paquets. C’est une autre enquête, et c’est là que les problèmes liés à la taille deviennent plausibles pour la première fois.
Étape trois : quelle clé a répondu
Une fois le transport établi, le client vérifie la clé d’hôte du serveur. Un rejet ici est une affirmation sur l’identité, pas sur la cryptographie : le pair a présenté une clé que votre politique n’accepte pas. Traitez cela comme une condition d’arrêt et vérifiez hors bande, auprès de la console ou de l’opérateur qui a reconstruit l’hôte. Supprimer l’entrée mémorisée pour effacer l’avertissement est le seul raccourci à refuser, car il détruit la preuve que quelque chose a répondu de façon inattendue.
Si l’hôte a réellement été reconstruit, retirez l’enregistrement obsolète seulement après confirmation de la nouvelle empreinte, et notez la date et la raison. L’ingénieur suivant rencontrera le même avertissement et a besoin de ce contexte.
Étapes quatre et cinq : compte contre autorisation
L’authentification est la quatrième frontière. Des identifiants refusés signifient que le serveur a évalué la tentative et l’a refusée ; vérifiez le compte, le type d’identifiant accepté par le serveur et la politique du serveur lui-même plutôt que le mot de passe VPN. La cinquième frontière est l’autorisation après une connexion réussie. Un utilisateur authentifié peut encore se voir refuser un shell, une commande, un sous-système ou un transfert, et ces refus ressemblent à des pannes pour qui ne lit que la dernière ligne du client.
| Last stage reached | What it proves | Where to look next |
|---|---|---|
| No TCP connection | No SSH transport exists | Address, port, route, selectors, filter, listener |
| TCP up, exchange incomplete | Reachability is not the blocker | Server response, negotiation, packet handling |
| Host identity rejected | The peer is not the expected host | Independently verified host key |
| User authentication rejected | The attempt reached authentication | Account, credential and server policy |
| Authenticated, session denied | Login succeeded, the operation did not | Shell, command or forwarding permission |
Arrêtez-vous après quelques tentatives de mot de passe échouées. Les suppositions répétées produisent des verrouillages qui ressemblent ensuite à une seconde panne sans rapport et coûtent plus de temps que le ticket initial.
Retour arrière et le journal que vous gardez
Changez une chose à la fois et notez ce que vous avez changé avant de retester. Si un changement aggrave la tentative, revenez dessus immédiatement au lieu d’empiler une autre correction par-dessus. Répétez l’opération d’origine depuis le client et le contexte d’origine. Une connexion réussie depuis une autre machine, sur une autre famille d’adresses, n’est pas une reproduction et ne prouve pas la correction.
Assainissez ce que vous partagez. La sortie détaillée du client peut porter des noms internes, des libellés de compte, des chemins de clés et des identifiants de clés publiques, alors publiez la conclusion par étapes plutôt qu’une trace brute.