STelnet refuse de se connecter, Xshell affiche une erreur d'algorithme, ou l'invite de mot de passe ne cesse de revenir en boucle. Chacun de ces cas correspond à un texte client bien réel, et ce texte indique déjà à quelle étape de la négociation SSH la panne se situe. Cette note est une référence rapport par rapport — le texte exact, la cause racine et la commande de correction pour chacun, tirés de cas réels côté commutateur.
Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026
Quel que soit le message affiché par le client, il est rarement vague par accident — il vous indique précisément à quelle étape de la négociation il n'est pas parvenu à passer.
Les échecs de connexion SSH sont bien trop souvent traités comme un problème unique et indifférencié, alors qu'en réalité la formulation même du client permet déjà de le circonscrire. Xshell, PuTTY, OpenSSH sous Windows, et le client stelnet du commutateur lui-même rapportent les mêmes défaillances sous-jacentes de façons différentes — une incompatibilité de version se lit comme une réinitialisation de socket sur un client et comme une erreur de protocole nette sur un autre — mais en dessous, la panne se situe toujours à l'un de quatre points : la connexion TCP au port 22 lui-même, la négociation des algorithmes, la confiance de la clé d'hôte, ou l'échange AAA/mot de passe.
Ce qui suit est organisé selon le rapport littéral, pas au petit bonheur : le texte exact côté client, ce qui se passe réellement derrière, et la commande qui corrige le problème — quinze des rapports qui reviennent constamment, plus une courte liste de contrôle générique et cinq réponses de FAQ tirées du terrain.
Quatre étapes, dans un ordre strict — et un rapport provenant d'une étape ultérieure signifie que tout ce qui précède a déjà réussi.
Placer la formulation exacte que vous observez sur cette carte vous indique immédiatement lequel des quinze rapports ci-dessous s'applique réellement, et en écarte beaucoup d'autres.
Les légendes du schéma restent en anglais pour la clarté technique.
La plupart des quinze rapports ci-dessous n'ont besoin d'être lus qu'une fois les choses simples écartées.
Un cas de terrain n'est même pas un message d'erreur : STelnet met simplement dix à quinze secondes à se connecter, sans aucune défaillance nulle part. C'est presque toujours un client proposant une clé Diffie-Hellman group-exchange de 8192 bits — plus le module négocié est long, plus le commutateur met de temps à calculer la clé partagée, et ce choix est fait par le client, pas par le commutateur. Un client différent, ou une longueur négociée plus courte, corrige cela immédiatement ; il n'y a aucune panne à traquer.
<SwitchA> display ssh server status
SSH version :2.0
STELNET IPv4 server :Disable
SSH server source interface :
// STELNET disabled and no source interface configured -- two of the most common root causes below
<SwitchA> display users
User-Intf Delay Type Network Address AuthenStatus AuthorcmdFlag
34 VTY 0 00:00:14 TEL 192.168.2.34 pass no
35 VTY 1 00:00:03 TEL 192.168.3.181 pass no
// count the rows against display user-interface maximum-vty before assuming a config fault
<SwitchA> display aaa online-fail-record username taclab14
User online fail reason : Local Authentication user block
// this field alone often tells you which of the reports below you're actually looking atOrganisé selon le texte exact affiché à l'écran — la cause sous-jacente, et la commande qui corrige le problème.
SYMPTÔMELe client STelnet rapporte : Error: Failed to verify the server's public key, suivi d'une invite à exécuter ssh client first-time enable, juste après la saisie du nom d'utilisateur.
CAUSEC'est la toute première connexion de ce client vers ce serveur. Sans l'accès de première fois activé, le client n'a aucune copie enregistrée de la clé d'hôte du serveur à comparer, donc la vérification de confiance échoue purement et simplement au lieu de demander confirmation.
CORRECTIONActivez l'authentification de première fois sur le client afin qu'il puisse enregistrer la clé d'hôte lors de cette première connexion et la vérifier à chaque connexion suivante.
[SwitchA] display this
// confirm ssh client first-time enable is not already present
[SwitchA] ssh client first-time enableSYMPTÔMELe client OpenSSH rapporte : ssh_rsa_verify: RSA modulus too small: 512 < minimum 768 bits, puis key_verify failed for server_host_key.
CAUSELa paire de clés RSA locale du commutateur a été générée avec un module inférieur à la longueur que les clients SSH modernes acceptent — 512 bits, dans ce cas.
CORRECTIONRégénérez la paire de clés locale sur le serveur SSH avec un module plus long.
[SwitchA] rsa local-key-pair create
The range of public key size is (512 ~ 2048).
Input the bits in the modulus[default = 512]:1024SYMPTÔMELe client OpenSSH rapporte : RSA host key for x.x.x.x has changed and you have requested strict checking, avec un avertissement d'attaque de l'homme du milieu et une ligne Offending RSA key pointant vers une ligne précise dans known_hosts.
CAUSELa clé d'hôte du commutateur a légitimement changé — une régénération de clé, une unité de remplacement, un redémarrage après une réinitialisation d'usine — et le client compare avec une entrée désormais obsolète enregistrée précédemment.
CORRECTIONSur le client, supprimez l'entrée obsolète de known_hosts afin qu'il puisse apprendre la nouvelle clé à la prochaine connexion.
# on the SSH client
rm /root/.ssh/known_hostsSYMPTÔMELe commutateur agissant comme client SSH rapporte : Error: The number of public keys reached the upper limit(20), puis : Error: Failed to save the server's public key.
CAUSEUn commutateur agissant comme client STelnet enregistre la clé d'hôte de chaque nouveau serveur SSH auquel il se connecte pour la première fois, et le stockage local plafonne à 20 clés de serveur enregistrées.
CORRECTIONTrouvez une entrée dont vous n'avez plus besoin, supprimez sa liaison au serveur, puis supprimez la clé publique de pair sous-jacente pour libérer un emplacement.
[SwitchA] display ssh server-info
[SwitchA] undo ssh client 10.0.0.1 assign rsa-key
[SwitchA] display rsa peer-public-key brief
[SwitchA] undo rsa peer-public-key 10.0.0.1SYMPTÔMEXshell rapporte : Socket error Event: 32 Error: 10053, puis Connection closing...Socket close — avant même qu'un nom d'utilisateur ou un mot de passe n'ait été saisi.
CAUSELe commutateur a envoyé un RST TCP, fermant le socket. Dans le cas le plus courant, le débogage montre que le client a proposé une chaîne de version SSH-1.x alors que le commutateur ne prend en charge que SSH-2.0/SSH-1.99, et l'étape de correspondance de version a échoué purement et simplement.
CORRECTIONForcez SSH2 sur le client. Si des clients SSH1 véritablement plus anciens doivent être pris en charge, chargez le plugin WEAKEA et activez la compatibilité côté serveur.
SSH/7/VERSION_RECEIVE:Version information received on VTY 3, version string:SSH-1.5-nsssh2_7.0.0031
SSH/7/VER_MATCH:Only support SSH-2.0 or SSH-1.99 when CompatibleSSH1x disabled, version match failed!
[SwitchA] ssh server compatible-ssh1x enable // only after loading the WEAKEA pluginSYMPTÔMELa sortie détaillée d'OpenSSH montre : debug1: Remote protocol version 1.99, remote software version -, suivi de debug1: no match: -.
CAUSEUne incompatibilité de bannière de version de protocole entre le client et le serveur empêche l'échange de se faire correctement.
CORRECTIONAlignez les deux côtés sur SSH2 — c'est à la fois l'option la plus sûre et celle par défaut sur les logiciels de commutateur actuels ; n'activez la compatibilité ssh1.x que si vraiment impossible de faire autrement.
SYMPTÔMEPuTTY rapporte : Couldn't agree a host key algorithm (available: rsa-sha2-512,rsa-sha2-256).
CAUSELe commutateur a proposé un ensemble d'algorithmes de clé d'hôte pour lesquels la liste préférée configurée dans PuTTY ne contient aucune correspondance.
CORRECTIONDans PuTTY, sous les paramètres SSH / Kex, forcez la version de protocole SSH préférée à 2 et réglez le repli sur toujours exécuter la version 2 ; si l'incompatibilité persiste, chargez plutôt le plugin WEAKEA sur le commutateur et élargissez-y la liste des algorithmes de clé d'hôte acceptés.
SYMPTÔMEXshell affiche une boîte de dialogue signalant no matching outgoing encryption algorithm ou no matching key exchange algorithm, et le journal du commutateur enregistre FailedReason=Failed to negotiate the encryption algorithm.
CAUSELes listes d'algorithmes du client et du commutateur pour le chiffrement, le HMAC ou l'échange de clés ne partagent aucune entrée commune — la négociation SSH choisit toujours le premier algorithme commun aux listes du serveur et du client, et s'il n'y en a aucun, elle échoue purement et simplement.
CORRECTIONOuvrez les paramètres de sécurité SSH du client (Connexion > SSH > Sécurité dans Xshell) et activez chaque option de chiffrement, HMAC et échange de clés listée ; comparez avec ce que le commutateur prend réellement en charge, et si aucun chevauchement ne se produit encore, chargez le plugin WEAKEA sur le commutateur pour élargir sa propre liste.
[Switch] display current-configuration | include ssh
ssh server cipher aes128_ctr
ssh server key-exchange dh_group14_sha256
[Switch] ssh server hmac ?
sha2_256 SHA2-256 HMAC algorithm, and this algorithm is recommended
// tick every equivalent box in the client's session security settingsSYMPTÔMELe commutateur rapporte Error: Failed to connect to the remote host, l'OpenSSH Windows rapporte ssh: connect to host x.x.x.x port 22: Connection refused, ou Xshell rapporte Could not connect to '10.54.4.71' (port 25): Connection failed — et le débogage ne montre rien du tout.
CAUSEDeux causes distinctes produisent exactement le même symptôme. Sur V200R020 et versions ultérieures, le commutateur n'accepte par défaut aucune demande de connexion SSH depuis aucune interface tant qu'une interface source n'est pas explicitement liée. Par ailleurs, le client peut simplement avoir le mauvais numéro de port, ou une ACL est liée au serveur SSH ou à l'interface utilisateur VTY et rejette silencieusement l'adresse du client.
CORRECTIONLiez une interface source de serveur SSH (ou toutes les interfaces) ; puis confirmez le numéro de port utilisé par le client et vérifiez à la fois ssh server acl et toute acl liée sous user-interface vty pour une règle refusant l'adresse du client.
[SwitchA] ssh server-source all-interface
[SwitchA] display current-configuration | include ssh
ssh server port 1500 // client must match this port exactly
ssh server acl 3333 // check this ACL for a deny rule on the client's IPSYMPTÔMEXshell demande le mot de passe, le mot de passe est saisi, et la même invite de mot de passe réapparaît simplement — jamais de message d'échec, jamais de succès. Le journal affiche FailedReason=User password authentication failed.
CAUSELe type d'authentification par défaut de l'utilisateur SSH a été supprimé avec undo ssh authentication-type default password, si bien que le processus SSH ne transmet jamais réellement les identifiants à AAA pour vérification — le débogage confirme qu'AAA ne reçoit jamais aucune requête.
CORRECTIONRestaurez password comme type d'authentification SSH par défaut, ou configurez-le explicitement par utilisateur.
[Switch] ssh authentication-type default password
// or, per user:
ssh user john
ssh user john authentication-type password
ssh user john service-type allSYMPTÔMESelon le client : le commutateur lui-même rapporte The connection was closed by the remote host ; l'OpenSSH Windows rapporte Received disconnect from x.x.x.x port 22:2: The connection is closed by SSH server ; IPOP rapporte Server sent disconnect message. Les trois apparaissent après plusieurs tentatives de mot de passe.
CAUSETrois mots de passe erronés en cinq minutes verrouille ce nom d'utilisateur pendant cinq minutes, et le serveur ferme activement la connexion au lieu de continuer à demander. Chaque client formule simplement différemment la même déconnexion côté serveur.
CORRECTIONConfirmez le blocage avec display local-user state block, puis attendez cinq minutes pour le déverrouillage automatique ou levez-le immédiatement dans la vue AAA. Si le compte est bloqué sur toutes les voies distantes à la fois, notre note sur la récupération après verrouillage de connexion au routeur couvre le retour par la console.
<Switch> display local-user state block
User-name State AuthMask AdminLevel BlockTime
taclab14 B TMSH 15 2023-12-20 08:38:22+08:00
[Switch] aaa
[Switch-aaa] undo local-aaa-user wrong-passwordSYMPTÔMELe journal enregistre : Failed to login. Reason: "The channel configuration is incorrect." — et chaque client ne rapporte qu'un délai dépassé ou une connexion refusée, sans autre détail ni sortie de débogage.
CAUSETous les canaux VTY sont déjà occupés. Le maximum par défaut est de 5 utilisateurs VTY simultanés, et une fois cette limite atteinte, les nouvelles sessions SSH ne peuvent tout simplement pas se voir attribuer de canal pour négocier.
CORRECTIONConfirmez avec display users et display user-interface maximum-vty, puis étendez la plage VTY et configurez l'authentification sur les lignes nouvellement disponibles.
<Switch> display user-interface maximum-vty
Maximum of VTY user : 5
[Switch] user-interface maximum-vty 15
[Switch] user-interface vty 5 14
[Switch-ui-vty5-14] authentication-mode aaa
[Switch-ui-vty5-14] protocol inbound sshSYMPTÔMELe journal enregistre FailedReason=The user's service type was incorrect, ou FailedReason=The user type was incorrcet (c'est bien l'orthographe littérale de la sortie de journal du commutateur) — après que le mot de passe lui-même a déjà été accepté.
CAUSEL'utilisateur SSH existe, mais son service-type n'inclut pas STelnet, ou le service-type de l'utilisateur AAA local correspondant est configuré pour une méthode d'accès entièrement différente.
CORRECTIONConfigurez à la fois le service-type de l'utilisateur SSH et celui de l'utilisateur local AAA pour inclure explicitement SSH.
ssh user john
ssh user john authentication-type password
ssh user john service-type all
[Switch-aaa] local-user john service-type sshSYMPTÔMELe journal enregistre SSH/4/SSH_FAIL avec FailedReason=User password authentication failed, mais le compte est authentifié par RADIUS et le mot de passe lui-même est correct.
CAUSEdebugging radius all montre que les valeurs des attributs Login-Service et Service-Type du serveur RADIUS ne correspondent pas à ce qu'une connexion SSH administrative attend — Service-Type doit être 6 (Administrative), et Login-Service doit inclure la valeur qui autorise SSH.
CORRECTIONCorrigez les valeurs des attributs Login-Service et Service-Type sur le serveur RADIUS lui-même, pas sur le commutateur.
[RDS(Evt):] Receive a packet(Code:authentication accept)
[Login-Service] [6] [0] // wrong
[Service-Type] [6] [1] // should be 6 (Administrative)SYMPTÔMELe journal enregistre SSH_FAIL(s) avec FailedReason=User public key authentication failed, alors même que la même connexion se termine avec succès par mot de passe quelques instants plus tard.
CAUSELe client n'a pas spécifié de méthode de connexion à l'avance. SSH tente par défaut l'authentification par clé publique en premier ; lorsque le client n'a pas configuré de clé, cette tentative échoue et est journalisée, puis le client se replie sur l'authentification par mot de passe, qui réussit. Il n'existe aucun moyen de supprimer cette ligne de journal spécifique.
CORRECTIONRien à corriger — c'est le comportement attendu lorsque l'authentification par clé publique est tentée en premier et que l'authentification par mot de passe est ce qui est réellement prévu.
Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
En tant que serveur : display this include-default | include ssh server. En tant que client : display this include-default | include ssh client. Les deux affichent les listes exactes de chiffrement, HMAC, échange de clés et clé publique en vigueur, qu'elles aient été définies explicitement ou laissées par défaut.
Les logiciels de commutateur récents sont livrés sans algorithmes faibles activés par défaut pour des raisons de sécurité. Chargez le plugin WEAKEA (install-module sur V200, install feature-software WEAKEA sur V600), puis annulez les commandes spécifiques ssh server/client cipher, hmac, key-exchange et publickey pour revenir à une liste incluant les anciennes options plus faibles — et relancez ssh server-source all-interface, car V200R020 et versions ultérieures n'acceptent par défaut aucune connexion sur aucune interface.
Un commutateur Huawei exécutant stelnet host-ip ne déclenche rien vers le serveur — pas même une connexion TCP — tant que vous n'avez pas réellement saisi le nom d'utilisateur. Le ssh natif de Windows et Xshell établissent tous deux la connexion TCP immédiatement au lancement, avant qu'un nom d'utilisateur ne soit saisi. Cette seule différence explique beaucoup de comportements autrement déroutants à la toute première invite.
Un online-fail-record vide signifie généralement qu'AAA n'a jamais reçu la requête du tout, ce qui pointe en amont de l'authentification — vérifiez si le type d'authentification SSH par défaut est configuré, si le débogage montre que le processus SSH atteint l'étape d'authentification, et si une ACL VTY ou serveur SSH rejette silencieusement le client avant qu'il n'y parvienne.
Souvent oui, mais l'ordre de diagnostic diffère suffisamment pour mériter sa propre approche en couches — voir notre note de diagnostic SSH hors ligne pour équipement AntiDDoS pour la décomposition en six couches lorsqu'un équipement de sécurité perd spécifiquement la gestion basée sur SSH.
Cette note s'appuie sur les commandes serveur/client SSH des commutateurs Huawei série S et leur sortie de journal, ainsi que sur les cas de terrain qui les sous-tendent. La formulation des clients tiers (Xshell, PuTTY, OpenSSH) est citée telle qu'observée, mais la formulation exacte peut varier selon la version du client. Elle ne couvre pas en profondeur les modes de défaillance spécifiques à SFTP/SCP, ni les scénarios de tunneling SSH et de redirection de port.
Envoyez-nous le texte exact affiché à l'écran — côté client et côté serveur si vous les avez tous les deux — et nous vous aiderons à le situer sur la carte.