SecoManager says the device is offline, but the box itself never went anywhere — it's still scrubbing traffic, still reachable on the LAN, still powered. The fault almost always sits in the SSH/STelnet path SecoManager uses to poll status. This is the six layers to check in order, with the real error messages and diagnostic commands for each.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
The device shows a red Offline flag, but nothing about its own health changed — the fault is almost always in the channel SecoManager uses to ask, not in the device being asked.
SecoManager decides a device is offline when its own periodic SSH/STelnet status poll stops succeeding — not when the device itself has actually failed. That distinction matters, because it means the fix is very rarely inside the AntiDDoS device's defense configuration, and almost always somewhere in the six layers underneath the SSH session itself: physical reachability, the STelnet connection, the account credentials, the device's own SSH password expiry, account or IP lockout triggered by SecoManager's own repeated polling, the SecoManager License state, and finally the SSH key-exchange and cipher suite the two sides are actually negotiating.
What follows is those six layers in the order worth checking them, the exact error messages and commands for each, four gotchas that explain most real cases, and field-case FAQ answers for the ones that don't fit cleanly into a single layer.
Work from the bottom of the stack up — physical reachability first, cipher negotiation last — because a lower layer failing makes every layer above it look broken too.
Each layer below rules out an entire class of explanations before you move to the next one; skipping straight to the SSH cipher configuration when the device's SSH password simply expired wastes far more time than it saves.
Diagram labels are kept in English for engineering clarity.
Layers 3 through 5 are the ones that get missed most often, because they all present the exact same symptom — Offline in SecoManager — while looking completely unrelated to each other underneath.
Each layer has its own test and its own fix — and most real cases resolve at layer 3, 4 or 6, not at the bottom or the top.
Before touching SSH at all, confirm the device itself is actually alive — this step alone rules out a hardware or power problem masquerading as a management-plane fault.
// 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 tooSecoManager showing Offline is a report about its own polling, not a direct measurement of the device — confirm the underlying STelnet session yourself before trusting the dashboard.
A “communication exception” reported by the newly installed system can point somewhere other than the device credentials entirely.
This is the layer that explains the classic case: the device ran online for a long stretch, then suddenly reports Down with no configuration change on either side.
<AntiDDoS12008>sys
[AntiDDoS12008]aaa
[AntiDDoS12008-aaa] local-aaa-user password policy administrator
[AntiDDoS12008-aaa-lupp-admin]password expire 0This is the layer that's easy to miss because the cause is SecoManager itself, repeatedly retrying a login that's already failing.
SSH working perfectly from the SecoManager server while the SecoManager Web page still reports failure is the specific symptom of this layer.
If the SSH key-exchange algorithm configured on the AntiDDoS device is insufficient, it simply can't exchange keys with SecoManager — with no password problem anywhere in sight.
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.logOnce the cipher and key-exchange configuration lines up, work through the surrounding SSH/STelnet configuration items in order — user service type, authentication type, VTY channel and the interface's Telnet service permission all have to be consistent, not just the cipher suite.
// 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 3Once the six-layer diagnosis above has told you roughly where the problem sits, these four account for most of what's actually happening.
SYMPTOMThe device was online and stable for an extended period with no configuration change on either side, then suddenly reports a Down alarm out of nowhere.
CAUSEThe device's own SSH/STelnet account password has an expiry policy attached, and it silently expired. SecoManager's polling login starts failing the moment the password can no longer authenticate, which surfaces purely as a status flag with nothing else pointing at the actual cause.
FIXSTelnet-login to the device directly with Xshell or similar to confirm the password prompt. Change the device password if it's expired or about to expire, update SecoManager's paired password to match, then set password expire 0 on the account so this doesn't recur silently.
<AntiDDoS12008>sys
[AntiDDoS12008]aaa
[AntiDDoS12008-aaa] local-aaa-user password policy administrator
[AntiDDoS12008-aaa-lupp-admin]password expire 0SYMPTOMSSH login from the SecoManager server to the device fails outright, even though the credentials you're typing by hand are correct.
CAUSESecoManager polls the device's status on a fixed, repeated schedule. If the device password was ever entered incorrectly — even once, even briefly — SecoManager's own automatic repeated queries can be enough on their own to lock the account or blacklist the server's IP address after just a few failed attempts, without any person manually retrying anything.
FIXConfirm there's no firewall policy between SecoManager and the device blocking SSH port 22 first, then check for account or IP lockout specifically as a side effect of repeated automatic polling — not a one-off human login mistake — before assuming the credentials themselves are wrong.
SYMPTOMLogging in to the AntiDDoS device with SSH directly from the SecoManager server succeeds cleanly, but the SecoManager Web page keeps reporting a test failure regardless.
CAUSEIf the connection itself demonstrably works at the SSH level, the remaining explanation sits one layer up: the SecoManager License has no valid entry, or has expired, and that's what's actually blocking the Web-side status from updating — not anything about the device or its credentials.
FIXCheck the SecoManager License state directly and resolve any no-License or expired-License condition before spending more time re-testing the SSH path, which has already been proven to work.
SYMPTOMdisplay ssh server error and the SecoManager-side common.log both point at a publickey mismatch, with credentials and network reachability both already confirmed fine.
CAUSEThe SSH key-exchange algorithm and cipher suite configured on the AntiDDoS device don't include what SecoManager needs to negotiate a session — the two sides simply can't agree on how to exchange keys, which has nothing to do with whether the password is correct.
FIXCompare display cur | in ssh against the recommended cipher configuration and apply what's missing, then work through the surrounding SSH user, VTY and interface service-permission configuration — a correct cipher suite still won't connect if stelnet server enable or the VTY authentication mode is wrong alongside it.
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 3072Pulled straight from the field — the ones worth having an answer ready for.
Almost certainly not. SecoManager's status flag reflects the outcome of its own SSH/STelnet polling, not a direct hardware check. Log in to the device directly first — over STelnet or Console — before assuming anything about the device itself has failed. In the great majority of real cases, the device is fine and the polling path is the actual fault.
It tells you the SSH path itself works, which rules out credentials, network reachability and cipher mismatch all at once. What's left is almost always a SecoManager-side condition — most commonly the SecoManager License being unlicensed or expired — rather than anything about the device.
The device's local AAA password policy carries an expiry setting by default, and once it lapses, SecoManager's polling login simply stops authenticating with no other symptom. Setting password expire 0 under the relevant local-aaa-user password policy disables the expiry for that account — do this deliberately once you've confirmed the account and its use are meant to be long-lived, rather than leaving the device to silently drop offline again later.
Run display ssh server error under the Diagnostic View on the device itself, and cross-check the SecoManager side's /opt/oss/log/NCECOMMONE/ATICMgmtMS/common.log for the matching entry. Between the two, a publickey mismatch, a cipher mismatch or an authentication failure will usually be explicit rather than something you have to infer from the Offline flag alone.
At that point no command-line operation is possible at all, which puts this outside normal troubleshooting and into an emergency case. First confirm this genuinely doesn't disrupt an in-progress business flow, then collect the fault information you can and contact your distributor or Huawei's after-sales hotline directly rather than continuing to try commands that can't reach the device.
This note is built around the Huawei AntiDDoS device family managed through SecoManager over SSH/STelnet, and the field checklist behind why that management channel drops while the device itself keeps running. It assumes SecoManager is the management platform in question; a different NMS or a direct-CLI-only deployment follows a related but not identical checklist. It doesn't cover the SecoManager server's own OS-level network configuration in depth, or NMS high-availability failover scenarios.
Tell us which layer you're stuck at — password, lockout, License, or SSH cipher mismatch — plus the display ssh server error output, and we'll help you read it.