Accueil / Notes techniques / Dépannage SSH de l'équipement AntiDDoS hors ligne

L'équipement AntiDDoS s'affiche hors ligne : le diagnostic SSH/STelnet à six niveaux

SecoManager indique que l'équipement est hors ligne, mais l'appareil lui-même n'a jamais bougé — il continue de nettoyer le trafic, reste joignable sur le LAN, reste alimenté. La panne se trouve presque toujours dans le chemin SSH/STelnet que SecoManager utilise pour interroger le statut. Voici les six niveaux à vérifier dans l'ordre, avec les messages d'erreur réels et les commandes de diagnostic pour chacun.

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

Hors ligne dans SecoManager ne veut pas dire en panne dans la baie

L'équipement affiche un indicateur rouge Hors ligne, mais rien dans sa propre santé n'a changé — la panne se trouve presque toujours dans le canal que SecoManager utilise pour interroger, pas dans l'équipement interrogé.

SecoManager considère un équipement hors ligne lorsque son propre sondage périodique de statut SSH/STelnet cesse de réussir — pas lorsque l'équipement lui-même a réellement échoué. Cette distinction compte, car elle signifie que la correction se trouve très rarement dans la configuration de défense de l'équipement AntiDDoS, et presque toujours quelque part dans les six niveaux sous la session SSH elle-même : accessibilité physique, connexion STelnet, identifiants du compte, expiration du mot de passe SSH propre à l'équipement, verrouillage de compte ou d'IP déclenché par le propre sondage répété de SecoManager, état de la licence SecoManager, et enfin l'algorithme d'échange de clés et la suite de chiffrement que les deux côtés négocient réellement.

Voici ces six niveaux dans l'ordre où il vaut la peine de les vérifier, les messages d'erreur et commandes exacts pour chacun, quatre pièges qui expliquent la plupart des cas réels, et des réponses de terrain pour ceux qui ne rentrent proprement dans aucun niveau unique.

Six niveaux entre « en ligne » et « hors ligne »

Travaillez du bas de la pile vers le haut — accessibilité physique d'abord, négociation de chiffrement en dernier — car une panne à un niveau inférieur fait paraître cassé chaque niveau au-dessus.

Chaque niveau ci-dessous écarte toute une catégorie d'explications avant de passer au suivant ; sauter directement à la configuration du chiffrement SSH alors que le mot de passe SSH de l'équipement a simplement expiré fait perdre bien plus de temps que cela n'en économise.

Les légendes du schéma restent en anglais pour la clarté technique.

Les niveaux 3 à 5 sont ceux qu'on manque le plus souvent, car ils présentent tous exactement le même symptôme — Hors ligne dans SecoManager — tout en étant totalement sans rapport les uns avec les autres en dessous.

Parcourir les six niveaux

Chaque niveau a son propre test et sa propre correction — et la plupart des cas réels se résolvent au niveau 3, 4 ou 6, pas tout en bas ni tout en haut.

Niveau 0 — Pouvez-vous seulement joindre l'équipement ?

Avant de toucher au SSH, confirmez d'abord que l'équipement lui-même est bien vivant — cette seule étape écarte un problème matériel ou d'alimentation déguisé en panne du plan de gestion.

Si la connexion distante Telnet/STelnet à l'équipement échoue, essayez d'abord la connexion par le port Console. Si la connexion Console échoue aussi, aucune opération en ligne de commande n'est possible du tout, et cela devient un cas d'urgence — collectez les informations de panne et contactez immédiatement votre distributeur ou la hotline après-vente Huawei.
Vérifiez la chaîne d'alimentation : si tous les voyants de l'équipement sont éteints et que les ventilateurs ne tournent pas, suspectez le système d'alimentation lui-même. Vérifiez si les interrupteurs de l'équipement ou du module d'alimentation sont bien activés, et confirmez que les voyants Input et Output du module d'alimentation sont allumés ; sinon, vérifiez la ligne d'alimentation de la salle/baie/armoire, ou intervertissez avec un module d'alimentation dont vous savez qu'il fonctionne pour vérifier par recoupement.
Si la connexion Console échoue aussi, vérifiez si les paramètres de communication du terminal série correspondent au port Console de l'équipement — par défaut 9600 bps, 8 bits de données, 1 bit d'arrêt, sans parité, sans contrôle de flux.
En dernier recours à ce niveau, essayez de réinitialiser l'équipement — l'éteindre puis le rallumer — pour voir si la panne disparaît.

// Console port default communication parameters:
// 9600 bps, 8 data bits, 1 stop bit, no parity, no flow control
// -- confirm the terminal emulator on your laptop is set to match before assuming Console is dead too

Niveau 1 — Manuellement, STelnet se connecte-t-il réellement ?

SecoManager affichant Hors ligne est un rapport sur son propre sondage, pas une mesure directe de l'équipement — confirmez vous-même la session STelnet sous-jacente avant de faire confiance au tableau de bord.

Vérifiez manuellement si STelnet se connecte normalement en vous connectant directement à l'équipement.
Si le test manuel réussit avec le bon nom d'utilisateur et mot de passe, la connexion STelnet elle-même va bien. La page de SecoManager peut simplement être obsolète — elle n'a peut-être pas encore été rafraîchie, et il vaut la peine de revérifier un instant plus tard après un rafraîchissement avant de supposer une vraie panne.
Si le test manuel échoue, la connexion STelnet ne s'établit véritablement pas, et vous devriez continuer vers les niveaux suivants plutôt que d'attendre que SecoManager se rafraîchisse de lui-même.

Niveau 2 — Le nom d'utilisateur et le mot de passe sont-ils réellement corrects ?

Une « exception de communication » signalée par le système nouvellement installé peut pointer vers autre chose que les identifiants de l'équipement.

Utilisez un outil tel que Xshell pour tester si le compte et le mot de passe STelnet sont corrects, ou ont simplement expiré.
Si le rapport indique spécifiquement « exception de communication », cela peut signifier que l'instance SecoManager a été installée sans le module qui gère les équipements AntiDDoS (le collecteur, les objets de protection et fonctions associées regroupés avec la gestion AntiDDoS). Si vous utilisez un installateur en version convergée, assurez-vous qu'AntiDDoS a été explicitement sélectionné comme produit lors de l'installation.

Niveau 3 — Le mot de passe SSH propre à l'équipement vient-il d'expirer ?

C'est le niveau qui explique le cas classique : l'équipement a fonctionné en ligne pendant longtemps, puis signale soudainement Down sans aucun changement de configuration de part et d'autre.

Si l'équipement fonctionnait normalement en ligne pendant un moment puis signale soudainement une alarme Down, suspectez que le mot de passe STelnet de l'équipement a expiré.
Utilisez Xshell ou un outil similaire pour vous connecter en STelnet directement à l'équipement AntiDDoS et vérifier si le mot de passe est correct. Si l'équipement indique que le mot de passe est sur le point d'expirer et doit être changé, changez le mot de passe de l'équipement, puis mettez à jour le mot de passe apparié sur SecoManager et retestez la connectivité.
Pour éviter que cela ne se reproduise, configurez la politique de mot de passe SSH sur l'équipement AntiDDoS pour qu'il n'expire pas.

<AntiDDoS12008>sys
[AntiDDoS12008]aaa
[AntiDDoS12008-aaa] local-aaa-user password policy administrator
[AntiDDoS12008-aaa-lupp-admin]password expire 0

Niveau 4 — Le propre sondage de SecoManager a-t-il verrouillé le compte ou l'IP ?

C'est le niveau facile à manquer parce que la cause est SecoManager lui-même, retentant sans cesse une connexion qui échoue déjà.

Essayez d'utiliser un client SSH pour vous connecter directement à l'équipement AntiDDoS depuis le serveur SecoManager. Si cela réussit mais que SecoManager ne peut toujours pas se connecter, les causes probables sont : un problème réseau entre SecoManager et l'équipement avec une restriction de politique pare-feu qui n'autorise pas le port SSH 22, ou le compte ou l'adresse IP du serveur se retrouvant verrouillés après des tentatives répétées de mot de passe erroné.
SecoManager sonde le statut de l'équipement AntiDDoS selon un calendrier régulier et répété. Si le mot de passe de l'équipement a été saisi incorrectementne serait-ce qu'une fois, les requêtes répétées automatiques de SecoManager peuvent verrouiller le compte ou l'adresse IP après seulement quelques tentatives échouées.

Niveau 5 — Est-ce en réalité un problème de licence SecoManager déguisé ?

SSH fonctionnant parfaitement depuis le serveur SecoManager alors que la page Web SecoManager signale toujours un échec est le symptôme spécifique de ce niveau.

Si vous pouvez vous connecter en SSH directement à l'équipement AntiDDoS depuis le serveur SecoManager, mais que la page Web SecoManager affiche toujours un échec de test obsolète, vérifiez si la licence SecoManager est normale. Résolvez d'abord toute condition d'absence de licence ou de licence expirée, avant de dépanner quoi que ce soit d'autre.

Niveau 6 — L'algorithme d'échange de clés SSH et la suite de chiffrement correspondent-ils réellement ?

Si l'algorithme d'échange de clés SSH configuré sur l'équipement AntiDDoS est insuffisant, il ne peut tout simplement pas échanger de clés avec SecoManager — sans aucun problème de mot de passe en vue.

Vérifiez la configuration de chiffrement SSH actuelle sur l'équipement.
Comparez-la à la configuration de chiffrement SSH recommandée.
Utilisez display ssh server error de la vue diagnostique pour vérifier les informations de diagnostic SSH, et vérifiez /opt/oss/log/NCECOMMONE/ATICMgmtMS/common.log côté SecoManager pour l'erreur correspondante.
Si l'erreur indique une discordance de publickey, cela signifie qu'il manque du contenu côté équipement qu'il faut compléter — vérifiez un par un les éléments de configuration SSH ci-dessous.

display cur | in ssh
// current SSH cipher configuration on the device

// recommended SSH cipher configuration:
ssh server cipher aes256_gcm aes128_gcm aes256_ctr aes192_ctr aes128_ctr
ssh server hmac sha2_512 sha2_256
ssh server key-exchange dh_group_exchange_sha256 dh_group16_sha512 curve25519_sha256
ssh server publickey ecc rsa
ssh server dh-exchange min-len 3072

// Diagnostic View:
display ssh server error
// SecoManager side: /opt/oss/log/NCECOMMONE/ATICMgmtMS/common.log

Une fois la configuration du chiffrement et de l'échange de clés alignée, parcourez dans l'ordre les éléments de configuration SSH/STelnet environnants — type de service utilisateur, type d'authentification, canal VTY et autorisation de service Telnet de l'interface doivent tous être cohérents, pas seulement la suite de chiffrement.

// check whether AntiDDoS SSH is configured, and whether Telnet is enabled
ssh user admin123 service-type all
// or
ssh user admin123 authentication-type all
// or
[Device-aaa] local-user admin123 service-type all
// or
stelnet server enable

// check whether the peer interface has telnet permitted
service-manage ssh permit

// check the SSH key-exchange configuration
ssh server cipher aes256_gcm aes128_gcm aes256_ctr aes192_ctr aes128_ctr
ssh server hmac sha2_512 sha2_256
ssh server key-exchange dh_group_exchange_sha256 dh_group16_sha512 curve25519_sha256
ssh server publickey ecc rsa
ssh server dh-exchange min-len 3072

// check the VTY channel configuration
user-interface vty 0 14
authentication-mode aaa
user privilege level 3

4 pièges qui expliquent la plupart des alarmes « Hors ligne »

Une fois que le diagnostic en six niveaux ci-dessus vous a indiqué approximativement où se situe le problème, ces quatre pièges expliquent la plupart de ce qui se passe réellement.

1. Un équipement qui fonctionnait bien depuis des mois s'affiche soudainement Down — le mot de passe vient d'expirer

SYMPTOML'équipement était en ligne et stable pendant une période prolongée sans changement de configuration de part et d'autre, puis signale soudainement une alarme Down sans raison apparente.

CAUSELe mot de passe du compte SSH/STelnet propre à l'équipement porte une politique d'expiration, et il a expiré silencieusement. La connexion de sondage de SecoManager commence à échouer dès l'instant où le mot de passe ne peut plus s'authentifier, ce qui se manifeste purement comme un indicateur de statut sans rien d'autre pointant vers la cause réelle.

FIXConnectez-vous en STelnet directement à l'équipement avec Xshell ou similaire pour confirmer l'invite de mot de passe. Changez le mot de passe de l'équipement s'il est expiré ou sur le point de l'être, mettez à jour le mot de passe apparié de SecoManager en conséquence, puis définissez password expire 0 sur le compte pour que cela ne se reproduise plus silencieusement.

<AntiDDoS12008>sys
[AntiDDoS12008]aaa
[AntiDDoS12008-aaa] local-aaa-user password policy administrator
[AntiDDoS12008-aaa-lupp-admin]password expire 0

2. Le propre sondage répété de SecoManager verrouille le compte ou l'IP

SYMPTOMLa connexion SSH du serveur SecoManager vers l'équipement échoue franchement, même si les identifiants que vous saisissez à la main sont corrects.

CAUSESecoManager sonde le statut de l'équipement selon un calendrier fixe et répété. Si le mot de passe de l'équipement a déjà été saisi incorrectement — même une fois, même brièvement — les propres requêtes automatiques répétées de SecoManager peuvent suffire à elles seules à verrouiller le compte ou mettre sur liste noire l'adresse IP du serveur après seulement quelques tentatives échouées, sans qu'aucune personne ne retente quoi que ce soit manuellement.

FIXConfirmez d'abord qu'aucune politique pare-feu entre SecoManager et l'équipement ne bloque le port SSH 22, puis vérifiez spécifiquement un verrouillage de compte ou d'IP comme effet secondaire du sondage automatique répété — pas une erreur de connexion humaine ponctuelle — avant de supposer que les identifiants eux-mêmes sont erronés.

3. Le SSH fonctionne manuellement, mais le Web SecoManager échoue toujours — vérifiez la licence, pas le mot de passe

SYMPTOMLa connexion SSH directe à l'équipement AntiDDoS depuis le serveur SecoManager réussit proprement, mais la page Web SecoManager continue de signaler un échec de test malgré tout.

CAUSESi la connexion elle-même fonctionne manifestement au niveau SSH, l'explication restante se trouve un niveau plus haut : la licence SecoManager n'a aucune entrée valide, ou a expiré, et c'est ce qui bloque réellement la mise à jour du statut côté Web — pas quoi que ce soit concernant l'équipement ou ses identifiants.

FIXVérifiez directement l'état de la licence SecoManager et résolvez toute condition d'absence de licence ou de licence expirée avant de passer plus de temps à retester le chemin SSH, dont il a déjà été prouvé qu'il fonctionne.

4. Discordance de publickey : la suite de chiffrement SSH de l'équipement est simplement trop faible pour dialoguer avec SecoManager

SYMPTOMdisplay ssh server error et le common.log côté SecoManager pointent tous deux vers une discordance de publickey, alors que les identifiants et l'accessibilité réseau ont déjà été confirmés corrects.

CAUSEL'algorithme d'échange de clés SSH et la suite de chiffrement configurés sur l'équipement AntiDDoS n'incluent pas ce dont SecoManager a besoin pour négocier une session — les deux côtés ne peuvent tout simplement pas s'entendre sur la façon d'échanger les clés, ce qui n'a rien à voir avec la correction du mot de passe.

FIXComparez display cur | in ssh à la configuration de chiffrement recommandée et appliquez ce qui manque, puis parcourez la configuration environnante des utilisateurs SSH, VTY et autorisation de service d'interface — une suite de chiffrement correcte ne se connectera toujours pas si stelnet server enable ou le mode d'authentification VTY est erroné à côté.

ssh server cipher aes256_gcm aes128_gcm aes256_ctr aes192_ctr aes128_ctr
ssh server hmac sha2_512 sha2_256
ssh server key-exchange dh_group_exchange_sha256 dh_group16_sha512 curve25519_sha256
ssh server publickey ecc rsa
ssh server dh-exchange min-len 3072

Cinq questions qui reviennent sans cesse

Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.

L'équipement s'affiche Hors ligne dans SecoManager mais je peux toujours le joindre directement sur le LAN — est-il réellement en panne ?

Presque certainement pas. L'indicateur de statut de SecoManager reflète le résultat de son propre sondage SSH/STelnet, pas une vérification matérielle directe. Connectez-vous d'abord directement à l'équipement — via STelnet ou Console — avant de supposer que quoi que ce soit concernant l'équipement lui-même a échoué. Dans la grande majorité des cas réels, l'équipement va bien et le chemin de sondage est la panne réelle.

Xshell peut se connecter à l'équipement sans problème, mais la page Web de SecoManager échoue sans cesse — que cela m'indique-t-il ?

Cela vous indique que le chemin SSH lui-même fonctionne, ce qui écarte d'un coup les identifiants, l'accessibilité réseau et la discordance de chiffrement. Ce qui reste est presque toujours une condition côté SecoManager — le plus souvent la licence SecoManager non licenciée ou expirée — plutôt que quoi que ce soit concernant l'équipement.

Quel est le comportement d'expiration de mot de passe par défaut sur l'équipement AntiDDoS, et comment le désactiver en toute sécurité ?

La politique de mot de passe AAA locale de l'équipement porte un réglage d'expiration par défaut, et une fois qu'il expire, la connexion de sondage de SecoManager cesse simplement de s'authentifier sans autre symptôme. Définir password expire 0 sous la local-aaa-user password policy concernée désactive l'expiration pour ce compte — faites-le délibérément une fois confirmé que le compte et son usage sont censés être durables, plutôt que de laisser l'équipement retomber silencieusement hors ligne plus tard.

Où trouver réellement la vraie raison de l'échec d'une négociation SSH, au lieu de deviner ?

Exécutez display ssh server error sous la vue diagnostique de l'équipement lui-même, et croisez-le avec l'entrée correspondante du /opt/oss/log/NCECOMMONE/ATICMgmtMS/common.log côté SecoManager. Entre les deux, une discordance de publickey, une discordance de chiffrement ou un échec d'authentification seront généralement explicites plutôt qu'à déduire du seul indicateur Hors ligne.

Le port Console est aussi injoignable, en plus de l'échec de Telnet/STelnet — que faire maintenant ?

À ce stade, aucune opération en ligne de commande n'est possible du tout, ce qui sort du dépannage normal pour devenir un cas d'urgence. Confirmez d'abord que cela ne perturbe véritablement pas un flux métier en cours, puis collectez les informations de panne que vous pouvez et contactez directement votre distributeur ou la hotline après-vente Huawei plutôt que de continuer à essayer des commandes qui ne peuvent pas atteindre l'équipement.

Limites honnêtes de cette note

Limites honnêtes de cette note

Cette note s'appuie sur la famille d'équipements Huawei AntiDDoS gérée via SecoManager par SSH/STelnet, et sur la liste de vérification de terrain expliquant pourquoi ce canal de gestion tombe en panne alors que l'équipement lui-même continue de fonctionner. Elle suppose que SecoManager est la plateforme de gestion en question ; un NMS différent ou un déploiement en CLI directe uniquement suit une liste de vérification apparentée mais non identique. Elle ne couvre pas en profondeur la configuration réseau au niveau OS du serveur SecoManager lui-même, ni les scénarios de basculement haute disponibilité du NMS.

L'équipement s'affiche toujours hors ligne ?

Dites-nous à quel niveau vous êtes bloqué — mot de passe, verrouillage, licence, ou discordance de chiffrement SSH — avec la sortie de display ssh server error, et nous vous aiderons à l'interpréter.

WhatsApp avec un ingénieur →