SecoManager indica que el equipo está fuera de línea, pero el equipo en sí nunca se movió — sigue limpiando tráfico, sigue siendo alcanzable en la LAN, sigue encendido. La falla casi siempre está en la ruta SSH/STelnet que SecoManager usa para consultar el estado. Estas son las seis capas a revisar en orden, con los mensajes de error reales y los comandos de diagnóstico para cada una.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
El equipo muestra una bandera roja de Fuera de línea, pero nada en su propia salud cambió — la falla casi siempre está en el canal que SecoManager usa para preguntar, no en el equipo al que se le pregunta.
SecoManager determina que un equipo está fuera de línea cuando su propio sondeo periódico de estado SSH/STelnet deja de tener éxito — no cuando el equipo mismo realmente falló. Esa distinción importa, porque significa que la solución muy rara vez está dentro de la configuración de defensa del equipo AntiDDoS, y casi siempre en algún lugar de las seis capas debajo de la propia sesión SSH: alcanzabilidad física, la conexión STelnet, las credenciales de la cuenta, el vencimiento de la propia contraseña SSH del equipo, el bloqueo de cuenta o IP provocado por el propio sondeo repetido de SecoManager, el estado de la licencia de SecoManager, y finalmente el algoritmo de intercambio de claves y el conjunto de cifrado que ambos lados realmente negocian.
A continuación, esas seis capas en el orden en que conviene revisarlas, los mensajes de error y comandos exactos para cada una, cuatro trampas que explican la mayoría de los casos reales, y respuestas de casos de campo para los que no encajan claramente en una sola capa.
Trabaje de abajo hacia arriba en la pila — alcanzabilidad física primero, negociación de cifrado al final — porque una capa inferior que falla hace que toda capa por encima también parezca rota.
Cada capa a continuación descarta toda una categoría de explicaciones antes de pasar a la siguiente; saltar directamente a la configuración de cifrado SSH cuando la contraseña SSH del equipo simplemente venció desperdicia mucho más tiempo del que ahorra.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Las capas 3 a 5 son las que más se pasan por alto, porque todas presentan exactamente el mismo síntoma — Fuera de línea en SecoManager — mientras que por debajo no tienen ninguna relación entre sí.
Cada capa tiene su propia prueba y su propia solución — y la mayoría de los casos reales se resuelven en la capa 3, 4 o 6, no en la más baja ni en la más alta.
Antes de tocar SSH siquiera, confirme que el propio equipo esté realmente vivo — este único paso descarta un problema de hardware o alimentación disfrazado de falla del plano de gestión.
// 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 tooQue SecoManager muestre Fuera de línea es un reporte sobre su propio sondeo, no una medición directa del equipo — confirme usted mismo la sesión STelnet subyacente antes de confiar en el panel.
Una “excepción de comunicación” reportada por el sistema recién instalado puede apuntar a algo completamente distinto de las credenciales del equipo.
Esta es la capa que explica el caso clásico: el equipo estuvo en línea durante mucho tiempo, y de repente reporta Down sin ningún cambio de configuración en ninguno de los dos lados.
<AntiDDoS12008>sys
[AntiDDoS12008]aaa
[AntiDDoS12008-aaa] local-aaa-user password policy administrator
[AntiDDoS12008-aaa-lupp-admin]password expire 0Esta es la capa fácil de pasar por alto porque la causa es el propio SecoManager, reintentando repetidamente un inicio de sesión que ya está fallando.
Que SSH funcione perfectamente desde el servidor de SecoManager mientras la página Web de SecoManager sigue reportando fallo es el síntoma específico de esta capa.
Si el algoritmo de intercambio de claves SSH configurado en el equipo AntiDDoS es insuficiente, simplemente no puede intercambiar claves con SecoManager — sin ningún problema de contraseña a la vista.
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.logUna vez que la configuración de cifrado e intercambio de claves esté alineada, recorra en orden los elementos de configuración SSH/STelnet circundantes — el tipo de servicio de usuario, el tipo de autenticación, el canal VTY y el permiso de servicio Telnet de la interfaz deben ser todos consistentes, no solo el conjunto de cifrado.
// 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 3Una vez que el diagnóstico de seis capas anterior le ha indicado más o menos dónde está el problema, estas cuatro trampas explican la mayor parte de lo que realmente está sucediendo.
SYMPTOMEl equipo estuvo en línea y estable durante un período prolongado sin ningún cambio de configuración en ninguno de los dos lados, y de repente reporta una alarma Down de la nada.
CAUSELa propia contraseña de la cuenta SSH/STelnet del equipo tiene adjunta una política de vencimiento, y venció silenciosamente. El inicio de sesión de sondeo de SecoManager empieza a fallar en el momento en que la contraseña ya no puede autenticar, lo cual se manifiesta puramente como una bandera de estado sin nada más que apunte a la causa real.
FIXInicie sesión por STelnet directamente en el equipo con Xshell o similar para confirmar el aviso de contraseña. Cambie la contraseña del equipo si venció o está por vencer, actualice la contraseña emparejada de SecoManager para que coincida, luego configure password expire 0 en la cuenta para que esto no vuelva a ocurrir en silencio.
<AntiDDoS12008>sys
[AntiDDoS12008]aaa
[AntiDDoS12008-aaa] local-aaa-user password policy administrator
[AntiDDoS12008-aaa-lupp-admin]password expire 0SYMPTOMEl inicio de sesión SSH desde el servidor de SecoManager al equipo falla rotundamente, aunque las credenciales que escribe a mano sean correctas.
CAUSESecoManager sondea el estado del equipo según un calendario fijo y repetido. Si la contraseña del equipo se ingresó incorrectamente alguna vez — aunque sea una vez, aunque sea brevemente — las propias consultas automáticas repetidas de SecoManager pueden bastar por sí solas para bloquear la cuenta o poner en lista negra la dirección IP del servidor tras solo unos pocos intentos fallidos, sin que ninguna persona reintente nada manualmente.
FIXConfirme primero que no haya ninguna política de firewall entre SecoManager y el equipo bloqueando el puerto SSH 22, luego revise específicamente el bloqueo de cuenta o IP como efecto secundario del sondeo automático repetido — no un error de inicio de sesión humano puntual — antes de asumir que las propias credenciales están mal.
SYMPTOMIniciar sesión por SSH directamente en el equipo AntiDDoS desde el servidor de SecoManager tiene éxito de forma limpia, pero la página Web de SecoManager sigue reportando un fallo de prueba de todos modos.
CAUSESi la conexión en sí demostrablemente funciona a nivel SSH, la explicación restante está un nivel más arriba: la licencia de SecoManager no tiene una entrada válida, o venció, y eso es lo que realmente está bloqueando la actualización del estado del lado Web — no nada sobre el equipo o sus credenciales.
FIXVerifique directamente el estado de la licencia de SecoManager y resuelva cualquier condición de sin licencia o licencia vencida antes de dedicar más tiempo a volver a probar la ruta SSH, que ya se demostró que funciona.
SYMPTOMdisplay ssh server error y el common.log del lado de SecoManager apuntan ambos a una discordancia de publickey, mientras que las credenciales y la alcanzabilidad de red ya se confirmaron correctas.
CAUSEEl algoritmo de intercambio de claves SSH y el conjunto de cifrado configurados en el equipo AntiDDoS no incluyen lo que SecoManager necesita para negociar una sesión — los dos lados simplemente no pueden ponerse de acuerdo sobre cómo intercambiar claves, lo cual no tiene nada que ver con si la contraseña es correcta.
FIXCompare display cur | in ssh con la configuración de cifrado recomendada y aplique lo que falte, luego recorra la configuración circundante de usuario SSH, VTY y permiso de servicio de interfaz — un conjunto de cifrado correcto aun así no se conectará si stelnet server enable o el modo de autenticación VTY está mal junto a él.
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 3072Extraídas directamente del campo — las que vale la pena tener respondidas de antemano.
Casi con toda seguridad no. La bandera de estado de SecoManager refleja el resultado de su propio sondeo SSH/STelnet, no una verificación directa de hardware. Inicie sesión directamente en el equipo primero — por STelnet o Console — antes de asumir que algo del propio equipo falló. En la gran mayoría de los casos reales, el equipo está bien y la ruta de sondeo es la falla real.
Le dice que la propia ruta SSH funciona, lo cual descarta credenciales, alcanzabilidad de red y discordancia de cifrado todo a la vez. Lo que queda es casi siempre una condición del lado de SecoManager — más comúnmente la licencia de SecoManager sin licencia o vencida — en lugar de algo sobre el equipo.
La política de contraseña AAA local del equipo lleva un ajuste de vencimiento por defecto, y una vez que caduca, el inicio de sesión de sondeo de SecoManager simplemente deja de autenticar sin ningún otro síntoma. Configurar password expire 0 bajo la local-aaa-user password policy correspondiente desactiva el vencimiento para esa cuenta — haga esto deliberadamente una vez que haya confirmado que la cuenta y su uso están destinados a ser duraderos, en lugar de dejar que el equipo vuelva a caer offline en silencio más adelante.
Ejecute display ssh server error bajo la Vista de diagnóstico en el propio equipo, y coteje con la entrada correspondiente en /opt/oss/log/NCECOMMONE/ATICMgmtMS/common.log del lado de SecoManager. Entre ambos, una discordancia de publickey, una discordancia de cifrado o un fallo de autenticación normalmente serán explícitos en lugar de algo que tenga que inferir solo de la bandera Fuera de línea.
En ese punto no es posible ninguna operación de línea de comandos en absoluto, lo cual saca esto de la resolución de problemas normal y lo convierte en un caso de emergencia. Primero confirme que esto genuinamente no interrumpe un flujo de negocio en curso, luego recopile la información de la falla que pueda y contacte directamente a su distribuidor o a la línea de atención posventa de Huawei en lugar de seguir intentando comandos que no pueden alcanzar el equipo.
Esta nota se basa en la familia de equipos Huawei AntiDDoS gestionada mediante SecoManager por SSH/STelnet, y en la lista de verificación de campo detrás de por qué ese canal de gestión cae mientras el propio equipo sigue funcionando. Asume que SecoManager es la plataforma de gestión en cuestión; un NMS distinto o un despliegue solo por CLI directa sigue una lista de verificación relacionada pero no idéntica. No cubre en profundidad la configuración de red a nivel de SO del propio servidor de SecoManager, ni escenarios de conmutación por error de alta disponibilidad del NMS.
Cuéntenos en qué capa está atascado — contraseña, bloqueo, licencia, o discordancia de cifrado SSH — junto con la salida de display ssh server error, y le ayudamos a interpretarla.