STelnet refuses to connect, Xshell throws an algorithm error, or the password prompt just keeps looping back on itself. Every one of these has a literal client-side string behind it, and that string already tells you which stage of the SSH handshake actually failed. This is a report-by-report reference — the exact text, the root cause, and the fix command for each, pulled from real switch-side field cases.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
Whatever the client is showing you, it's rarely vague by accident — it's telling you exactly which stage of the handshake it never got past.
SSH login failures get treated as a single undifferentiated problem far too often, when in fact the client's own wording already narrows it down. Xshell, PuTTY, OpenSSH on Windows, and the switch's own stelnet client all report the same underlying failures differently — a version mismatch reads as a socket reset on one client and a clean protocol error on another — but underneath, the fault always sits at one of four points: the TCP connection to port 22 itself, algorithm negotiation, host-key trust, or the AAA/password exchange.
What follows is organized by the literal report, not by guesswork: the exact client-side text, what's actually going on behind it, and the command that fixes it — fifteen of the reports that come up constantly, plus a short generic checklist and five FAQ answers from the field.
Four stages, in strict order — and a report from a later stage means everything before it already succeeded.
Placing the exact wording you're looking at on this map tells you immediately which of the fifteen reports below actually applies, and rules out a lot of the ones that don't.
Diagram labels are kept in English for engineering clarity.
Most of the fifteen reports below only need to be read once you've ruled out the plain stuff first.
One case in the field isn't an error message at all: STelnet just takes ten to fifteen seconds to log in, with no failure anywhere. That's almost always a client offering an 8192-bit Diffie-Hellman group-exchange key — the longer the negotiated modulus, the longer the switch spends computing the shared key, and that choice is made by the client, not the switch. A different client, or a shorter negotiated length, fixes it immediately; there's no fault to chase.
<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 atOrganized by the exact text on screen — the cause behind it, and the command that fixes it.
SYMPTOMSTelnet client reports: Error: Failed to verify the server's public key, followed by a prompt to run ssh client first-time enable, right after the username is entered.
CAUSEThis is the very first connection from this client to this server. Without first-time-access enabled, the client has no saved copy of the server's host key to check against, so the trust check fails outright rather than asking for confirmation.
FIXEnable first-time authentication on the client so it can save the host key on this first connection and check against it on every one after.
[SwitchA] display this
// confirm ssh client first-time enable is not already present
[SwitchA] ssh client first-time enableSYMPTOMOpenSSH client reports: ssh_rsa_verify: RSA modulus too small: 512 < minimum 768 bits, then key_verify failed for server_host_key.
CAUSEThe switch's local RSA key pair was generated with a modulus below the length modern SSH clients are willing to accept — 512 bits, in this case.
FIXRegenerate the local key pair on the SSH server with a longer modulus.
[SwitchA] rsa local-key-pair create
The range of public key size is (512 ~ 2048).
Input the bits in the modulus[default = 512]:1024SYMPTOMOpenSSH client reports: RSA host key for x.x.x.x has changed and you have requested strict checking, with a man-in-the-middle warning and an Offending RSA key line pointing at a specific line in known_hosts.
CAUSEThe switch's host key legitimately changed — a key regeneration, a replacement unit, a reload after a factory reset — and the client is comparing against a now-stale entry saved from before.
FIXOn the client, remove the stale entry from known_hosts so it can learn the new key on the next connection.
# on the SSH client
rm /root/.ssh/known_hostsSYMPTOMSwitch acting as an SSH client reports: Error: The number of public keys reached the upper limit(20), then: Error: Failed to save the server's public key.
CAUSEA switch acting as an STelnet client saves the host key of every new SSH server it connects to for the first time, and the local store caps out at 20 saved server keys.
FIXFind an entry you no longer need, remove its server binding, then delete the underlying peer public key to free up a slot.
[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.1SYMPTOMXshell reports: Socket error Event: 32 Error: 10053, then Connection closing...Socket close — before a username or password has even been entered.
CAUSEThe switch sent a TCP RST, closing the socket. In the most common case, debugging shows the client offered an SSH-1.x version string while the switch only supports SSH-2.0/SSH-1.99, and the version-match step failed outright.
FIXForce SSH2 on the client. If genuinely older SSH1 clients must be supported, load the WEAKEA plugin and enable server-side compatibility.
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 pluginSYMPTOMOpenSSH verbose output shows: debug1: Remote protocol version 1.99, remote software version -, followed by debug1: no match: -.
CAUSEA protocol-version banner mismatch between client and server prevents the exchange from matching up correctly.
FIXAlign both sides on SSH2 — it's both the safer and the default option on current switch software; enable ssh1.x compatibility only when there's no way around it.
SYMPTOMPuTTY reports: Couldn't agree a host key algorithm (available: rsa-sha2-512,rsa-sha2-256).
CAUSEThe switch offered a set of host-key algorithms that PuTTY's own preferred list, as configured, doesn't include a match for.
FIXIn PuTTY, under the SSH / Kex settings, force preferred SSH protocol version to 2 and set the fallback to always run version 2; if the mismatch persists, load the WEAKEA plugin on the switch and widen the accepted host-key algorithm list there instead.
SYMPTOMXshell shows a dialog reporting no matching outgoing encryption algorithm or no matching key exchange algorithm, and the switch log records FailedReason=Failed to negotiate the encryption algorithm.
CAUSEThe client's and the switch's algorithm lists for cipher, HMAC, or key exchange share no common entry — SSH negotiation always picks the first algorithm the server's list and the client's list have in common, and if there isn't one, it fails outright.
FIXOpen the client's SSH security settings (Connection > SSH > Security in Xshell) and enable every listed cipher, HMAC, and key-exchange option; compare against what the switch actually supports, and if there's still no overlap, load the WEAKEA plugin on the switch to widen its own list.
[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 settingsSYMPTOMSwitch reports Error: Failed to connect to the remote host, Windows OpenSSH reports ssh: connect to host x.x.x.x port 22: Connection refused, or Xshell reports Could not connect to '10.54.4.71' (port 25): Connection failed — and debugging shows nothing at all.
CAUSETwo distinct causes produce the exact same symptom. On V200R020 and later, the switch by default accepts no SSH login requests from any interface until a source interface is explicitly bound. Separately, the client may simply have the wrong port number, or an ACL is bound to the SSH server or the VTY user-interface and is quietly dropping the client's address.
FIXBind an SSH server source interface (or all interfaces); then confirm the port number the client is using and check both ssh server acl and any acl bound under user-interface vty for a rule denying the client's address.
[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 IPSYMPTOMXshell asks for the password, the password is entered, and the same password prompt simply reappears — never a failure message, never a success. The log shows FailedReason=User password authentication failed.
CAUSEThe SSH user's default authentication type was removed with undo ssh authentication-type default password, so the SSH process never actually forwards the credentials to AAA to check — debugging confirms AAA never receives a request at all.
FIXRestore password as the default SSH authentication type, or configure it explicitly per user.
[Switch] ssh authentication-type default password
// or, per user:
ssh user john
ssh user john authentication-type password
ssh user john service-type allSYMPTOMDepending on the client: the switch itself reports The connection was closed by the remote host; Windows OpenSSH reports Received disconnect from x.x.x.x port 22:2: The connection is closed by SSH server; IPOP reports Server sent disconnect message. All three appear after several password attempts.
CAUSEThree wrong passwords within five minutes locks that username for five minutes, and the server actively closes the connection rather than continuing to prompt. Each client just phrases the same server-side disconnect differently.
FIXConfirm the block with display local-user state block, then either wait five minutes for the automatic unlock or clear it immediately in the AAA view. If the account is locked out of every remote path at once, our router login lockout recovery note covers the console-level way back in.
<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-passwordSYMPTOMLog records: Failed to login. Reason: "The channel configuration is incorrect." — and every client just reports a timeout or connection-refused with no further detail and no debugging output.
CAUSEEvery VTY channel is already occupied. The default maximum is 5 concurrent VTY users, and once that's used up, new SSH sessions simply can't be assigned a channel to negotiate on.
FIXConfirm with display users and display user-interface maximum-vty, then extend the VTY range and configure authentication on the newly available lines.
<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 sshSYMPTOMLog records FailedReason=The user's service type was incorrect, or FailedReason=The user type was incorrcet (that's the literal spelling in the switch's own log output) — after the password itself was already accepted.
CAUSEThe SSH user exists, but its service-type doesn't include STelnet, or the corresponding AAA local user's service-type is configured for a different access method entirely.
FIXSet both the SSH user's service type and the AAA local user's service type to include SSH explicitly.
ssh user john
ssh user john authentication-type password
ssh user john service-type all
[Switch-aaa] local-user john service-type sshSYMPTOMLog records SSH/4/SSH_FAIL with FailedReason=User password authentication failed, but the account is RADIUS-authenticated and the password itself is correct.
CAUSEdebugging radius all shows the RADIUS server's Login-Service and Service-Type attribute values don't match what an administrative SSH login expects — Service-Type has to be 6 (Administrative), and Login-Service has to include the value that permits SSH.
FIXCorrect the Login-Service and Service-Type attribute values on the RADIUS server itself, not on the switch.
[RDS(Evt):] Receive a packet(Code:authentication accept)
[Login-Service] [6] [0] // wrong
[Service-Type] [6] [1] // should be 6 (Administrative)SYMPTOMLog records SSH_FAIL(s) with FailedReason=User public key authentication failed, even though the same login completes successfully with a password moments later.
CAUSEThe client didn't specify a login method up front. SSH tries public-key authentication first by default; when the client hasn't configured a key, that attempt fails and logs, then the client falls back to password authentication, which succeeds. There's no way to suppress this specific log line.
FIXNothing to fix — this is expected behavior when public-key auth is attempted first and password auth is what's actually intended.
Pulled straight from the field — the ones worth having an answer ready for.
As a server: display this include-default | include ssh server. As a client: display this include-default | include ssh client. Both show the exact cipher, HMAC, key-exchange, and public-key lists in effect, whether they were set explicitly or left at default.
Recent switch software ships without weak algorithms enabled by default for security reasons. Load the WEAKEA plugin (install-module on V200, install feature-software WEAKEA on V600), then undo the specific ssh server/client cipher, hmac, key-exchange and publickey commands to fall back to a list that includes the older, weaker options — and re-run ssh server-source all-interface, since V200R020 and later don't accept connections on any interface by default.
A Huawei switch running stelnet host-ip doesn't trigger anything toward the server — not even a TCP connection — until you've actually typed in the username. Windows' native ssh and Xshell both establish the TCP connection immediately on launch, before any username is entered. That difference alone explains a lot of otherwise-confusing behavior at the very first prompt.
An empty online-fail-record usually means AAA never received the request at all, which points upstream of authentication — check whether the default SSH authentication type is configured, whether debugging shows the SSH process reaching the authentication stage, and whether a VTY or SSH-server ACL is silently dropping the client before it gets that far.
Often yes, but the diagnostic order differs enough to deserve its own layered approach — see our AntiDDoS device offline SSH diagnosis note for the six-layer breakdown when a security device specifically drops off SSH-based management.
This note is built around Huawei S-series switch SSH server/client commands and log output, plus the field cases behind them. Third-party client wording (Xshell, PuTTY, OpenSSH) is quoted as observed, but exact phrasing can vary by client version. It doesn't cover SFTP/SCP-specific failure modes in depth, or SSH tunneling and port-forwarding scenarios.
Send us the exact text on screen — client and server side both, if you have them — and we'll help you place it on the map.