O STelnet se recusa a conectar, o Xshell mostra um erro de algoritmo, ou o prompt de senha simplesmente continua voltando em loop. Cada um desses casos tem por trás uma string real do lado do cliente, e essa string já indica em qual etapa do handshake SSH a falha realmente ocorreu. Esta é uma referência caso a caso — o texto exato, a causa raiz e o comando de correção para cada um, extraídos de casos reais de campo em switches.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
O que quer que o cliente esteja mostrando, raramente é vago por acidente — ele está dizendo exatamente em qual etapa do handshake não conseguiu avançar.
As falhas de login SSH são tratadas com frequência demais como um problema único e indiferenciado, quando na verdade a própria redação do cliente já reduz o escopo. Xshell, PuTTY, OpenSSH no Windows, e o próprio cliente stelnet do switch relatam as mesmas falhas subjacentes de formas diferentes — uma incompatibilidade de versão aparece como um reset de socket em um cliente e como um erro de protocolo limpo em outro — mas, por baixo, a falha sempre está em um de quatro pontos: a própria conexão TCP à porta 22, a negociação de algoritmos, a confiança da chave de host, ou a troca AAA/senha.
O que vem a seguir está organizado pelo relato literal, não por suposição: o texto exato do lado do cliente, o que realmente está acontecendo por trás, e o comando que resolve — quinze dos relatos que aparecem constantemente, além de uma breve lista de verificação genérica e cinco respostas de perguntas frequentes vindas do campo.
Quatro etapas, em ordem estrita — e um relato de uma etapa posterior significa que tudo antes dela já teve sucesso.
Colocar a redação exata que você está vendo neste mapa indica imediatamente qual dos quinze relatos abaixo realmente se aplica, e descarta muitos dos que não se aplicam.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
A maioria dos quinze relatos abaixo só precisa ser lida depois de descartar o óbvio primeiro.
Um caso de campo nem sequer é uma mensagem de erro: o STelnet simplesmente demora de dez a quinze segundos para logar, sem nenhuma falha em lugar algum. Isso quase sempre se deve a um cliente oferecendo uma chave Diffie-Hellman group-exchange de 8192 bits — quanto mais longo o módulo negociado, mais tempo o switch leva para calcular a chave compartilhada, e essa escolha é feita pelo cliente, não pelo switch. Um cliente diferente, ou um comprimento negociado mais curto, resolve isso imediatamente; não há falha a perseguir.
<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 atOrganizado pelo texto exato na tela — a causa por trás, e o comando que resolve.
SINTOMAO cliente STelnet reporta: Error: Failed to verify the server's public key, seguido por um aviso para executar ssh client first-time enable, logo após o nome de usuário ser digitado.
CAUSAEsta é a primeiríssima conexão deste cliente com este servidor. Sem o acesso de primeira vez habilitado, o cliente não tem nenhuma cópia salva da chave de host do servidor para comparar, então a verificação de confiança falha diretamente em vez de pedir confirmação.
CORREÇÃOHabilite a autenticação de primeira vez no cliente para que ele possa salvar a chave de host nesta primeira conexão e verificá-la em todas as seguintes.
[SwitchA] display this
// confirm ssh client first-time enable is not already present
[SwitchA] ssh client first-time enableSINTOMAO cliente OpenSSH reporta: ssh_rsa_verify: RSA modulus too small: 512 < minimum 768 bits, depois key_verify failed for server_host_key.
CAUSAO par de chaves RSA local do switch foi gerado com um módulo abaixo do comprimento que os clientes SSH modernos aceitam — 512 bits, neste caso.
CORREÇÃOGere novamente o par de chaves local no servidor SSH com um módulo mais longo.
[SwitchA] rsa local-key-pair create
The range of public key size is (512 ~ 2048).
Input the bits in the modulus[default = 512]:1024SINTOMAO cliente OpenSSH reporta: RSA host key for x.x.x.x has changed and you have requested strict checking, com um aviso de ataque man-in-the-middle e uma linha Offending RSA key apontando para uma linha específica em known_hosts.
CAUSAA chave de host do switch mudou legitimamente — uma regeneração de chave, uma unidade de substituição, uma reinicialização após um reset de fábrica — e o cliente está comparando com uma entrada agora desatualizada, salva anteriormente.
CORREÇÃONo cliente, remova a entrada desatualizada de known_hosts para que ele possa aprender a nova chave na próxima conexão.
# on the SSH client
rm /root/.ssh/known_hostsSINTOMAO switch atuando como cliente SSH reporta: Error: The number of public keys reached the upper limit(20), depois: Error: Failed to save the server's public key.
CAUSAUm switch atuando como cliente STelnet salva a chave de host de cada novo servidor SSH ao qual se conecta pela primeira vez, e o armazenamento local tem um limite de 20 chaves de servidor salvas.
CORREÇÃOEncontre uma entrada que não seja mais necessária, remova sua vinculação com o servidor, depois exclua a chave pública do peer subjacente para liberar uma vaga.
[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.1SINTOMAO Xshell reporta: Socket error Event: 32 Error: 10053, depois Connection closing...Socket close — antes mesmo de um nome de usuário ou senha ser digitado.
CAUSAO switch enviou um RST TCP, fechando o socket. No caso mais comum, o debugging mostra que o cliente ofereceu uma string de versão SSH-1.x enquanto o switch só suporta SSH-2.0/SSH-1.99, e a etapa de correspondência de versão falhou diretamente.
CORREÇÃOForce o SSH2 no cliente. Se clientes SSH1 realmente mais antigos precisarem ser suportados, carregue o plugin WEAKEA e habilite a compatibilidade do lado do servidor.
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 pluginSINTOMAA saída detalhada do OpenSSH mostra: debug1: Remote protocol version 1.99, remote software version -, seguido de debug1: no match: -.
CAUSAUma incompatibilidade no banner de versão de protocolo entre cliente e servidor impede que a troca corresponda corretamente.
CORREÇÃOAlinhe os dois lados em SSH2 — é tanto a opção mais segura quanto a padrão no software atual do switch; habilite a compatibilidade ssh1.x apenas quando realmente não houver alternativa.
SINTOMAO PuTTY reporta: Couldn't agree a host key algorithm (available: rsa-sha2-512,rsa-sha2-256).
CAUSAO switch ofereceu um conjunto de algoritmos de chave de host para os quais a lista preferida configurada no PuTTY não inclui nenhuma correspondência.
CORREÇÃONo PuTTY, nas configurações SSH / Kex, force a versão de protocolo SSH preferida para 2 e defina o fallback para sempre executar a versão 2; se a incompatibilidade persistir, carregue o plugin WEAKEA no switch e amplie lá a lista de algoritmos de chave de host aceitos.
SINTOMAO Xshell exibe uma caixa de diálogo reportando no matching outgoing encryption algorithm ou no matching key exchange algorithm, e o log do switch registra FailedReason=Failed to negotiate the encryption algorithm.
CAUSAAs listas de algoritmos do cliente e do switch para cifra, HMAC ou troca de chaves não compartilham nenhuma entrada em comum — a negociação SSH sempre escolhe o primeiro algoritmo em comum entre a lista do servidor e a do cliente, e se não houver nenhum, falha diretamente.
CORREÇÃOAbra as configurações de segurança SSH do cliente (Conexão > SSH > Segurança no Xshell) e habilite todas as opções de cifra, HMAC e troca de chaves listadas; compare com o que o switch realmente suporta, e se ainda não houver correspondência, carregue o plugin WEAKEA no switch para ampliar sua própria lista.
[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 settingsSINTOMAO switch reporta Error: Failed to connect to the remote host, o OpenSSH do Windows reporta ssh: connect to host x.x.x.x port 22: Connection refused, ou o Xshell reporta Could not connect to '10.54.4.71' (port 25): Connection failed — e o debugging não mostra absolutamente nada.
CAUSADuas causas distintas produzem exatamente o mesmo sintoma. No V200R020 e versões posteriores, o switch por padrão não aceita solicitações de login SSH de nenhuma interface até que uma interface de origem seja explicitamente vinculada. Separadamente, o cliente pode simplesmente ter o número de porta errado, ou uma ACL está vinculada ao servidor SSH ou à interface de usuário VTY e está descartando silenciosamente o endereço do cliente.
CORREÇÃOVincule uma interface de origem do servidor SSH (ou todas as interfaces); depois confirme o número de porta que o cliente está usando e verifique tanto ssh server acl quanto qualquer acl vinculada em user-interface vty em busca de uma regra que negue o endereço do cliente.
[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 IPSINTOMAO Xshell pede a senha, a senha é digitada, e o mesmo prompt de senha simplesmente reaparece — nunca uma mensagem de falha, nunca um sucesso. O log mostra FailedReason=User password authentication failed.
CAUSAO tipo de autenticação padrão do usuário SSH foi removido com undo ssh authentication-type default password, então o processo SSH nunca realmente encaminha as credenciais para o AAA verificar — o debugging confirma que o AAA nunca recebe nenhuma solicitação.
CORREÇÃORestaure password como o tipo de autenticação SSH padrão, ou configure-o explicitamente por usuário.
[Switch] ssh authentication-type default password
// or, per user:
ssh user john
ssh user john authentication-type password
ssh user john service-type allSINTOMADependendo do cliente: o próprio switch reporta The connection was closed by the remote host; o OpenSSH do Windows reporta Received disconnect from x.x.x.x port 22:2: The connection is closed by SSH server; o IPOP reporta Server sent disconnect message. Os três aparecem após várias tentativas de senha.
CAUSATrês senhas erradas em cinco minutos bloqueia esse nome de usuário por cinco minutos, e o servidor fecha ativamente a conexão em vez de continuar pedindo a senha. Cada cliente apenas expressa de forma diferente a mesma desconexão do lado do servidor.
CORREÇÃOConfirme o bloqueio com display local-user state block, depois espere cinco minutos para o desbloqueio automático ou remova-o imediatamente na visão AAA. Se a conta estiver bloqueada em todos os caminhos remotos ao mesmo tempo, nossa nota de recuperação de bloqueio de login do roteador cobre o retorno pelo 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-passwordSINTOMAO log registra: Failed to login. Reason: "The channel configuration is incorrect." — e cada cliente apenas reporta um tempo esgotado ou conexão recusada, sem mais detalhes nem saída de debugging.
CAUSATodos os canais VTY já estão ocupados. O máximo padrão é 5 usuários VTY simultâneos, e uma vez esgotado, novas sessões SSH simplesmente não conseguem receber um canal para negociar.
CORREÇÃOConfirme com display users e display user-interface maximum-vty, depois estenda o intervalo VTY e configure a autenticação nas linhas recém-disponíveis.
<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 sshSINTOMAO log registra FailedReason=The user's service type was incorrect, ou FailedReason=The user type was incorrcet (essa é a grafia literal na própria saída de log do switch) — depois que a própria senha já foi aceita.
CAUSAO usuário SSH existe, mas seu service-type não inclui STelnet, ou o service-type do usuário local AAA correspondente está configurado para um método de acesso completamente diferente.
CORREÇÃOConfigure tanto o service-type do usuário SSH quanto o do usuário local AAA para incluir SSH explicitamente.
ssh user john
ssh user john authentication-type password
ssh user john service-type all
[Switch-aaa] local-user john service-type sshSINTOMAO log registra SSH/4/SSH_FAIL com FailedReason=User password authentication failed, mas a conta é autenticada por RADIUS e a própria senha está correta.
CAUSAdebugging radius all mostra que os valores dos atributos Login-Service e Service-Type do servidor RADIUS não correspondem ao que um login SSH administrativo espera — Service-Type precisa ser 6 (Administrative), e Login-Service precisa incluir o valor que permite SSH.
CORREÇÃOCorrija os valores dos atributos Login-Service e Service-Type no próprio servidor RADIUS, não no switch.
[RDS(Evt):] Receive a packet(Code:authentication accept)
[Login-Service] [6] [0] // wrong
[Service-Type] [6] [1] // should be 6 (Administrative)SINTOMAO log registra SSH_FAIL(s) com FailedReason=User public key authentication failed, mesmo que o mesmo login seja concluído com sucesso usando senha momentos depois.
CAUSAO cliente não especificou um método de login antecipadamente. O SSH tenta a autenticação por chave pública primeiro por padrão; quando o cliente não configurou uma chave, essa tentativa falha e é registrada, depois o cliente recorre à autenticação por senha, que tem sucesso. Não há como suprimir essa linha de log específica.
CORREÇÃONada a corrigir — este é o comportamento esperado quando a autenticação por chave pública é tentada primeiro e a autenticação por senha é o que realmente se pretende.
Tiradas diretamente do campo — as que vale a pena ter uma resposta pronta.
Como servidor: display this include-default | include ssh server. Como cliente: display this include-default | include ssh client. Ambos mostram as listas exatas de cifra, HMAC, troca de chaves e chave pública em vigor, sejam elas configuradas explicitamente ou deixadas no padrão.
O software recente dos switches vem sem algoritmos fracos habilitados por padrão por motivos de segurança. Carregue o plugin WEAKEA (install-module no V200, install feature-software WEAKEA no V600), depois desfaça os comandos específicos ssh server/client cipher, hmac, key-exchange e publickey para voltar a uma lista que inclua as opções mais antigas e fracas — e execute novamente ssh server-source all-interface, já que o V200R020 e versões posteriores não aceitam conexões em nenhuma interface por padrão.
Um switch Huawei executando stelnet host-ip não dispara nada em direção ao servidor — nem mesmo uma conexão TCP — até que o nome de usuário seja realmente digitado. O ssh nativo do Windows e o Xshell estabelecem a conexão TCP imediatamente ao iniciar, antes de qualquer nome de usuário ser inserido. Só essa diferença já explica muito comportamento que de outra forma seria confuso logo no primeiro prompt.
Um online-fail-record vazio geralmente significa que o AAA nunca recebeu a solicitação, o que aponta para antes da autenticação — verifique se o tipo de autenticação SSH padrão está configurado, se o debugging mostra o processo SSH chegando à etapa de autenticação, e se uma ACL de VTY ou do servidor SSH está descartando silenciosamente o cliente antes que ele chegue até lá.
Frequentemente sim, mas a ordem de diagnóstico difere o suficiente para merecer sua própria abordagem em camadas — veja nossa nota de diagnóstico SSH de dispositivo AntiDDoS offline para o detalhamento em seis camadas quando um dispositivo de segurança especificamente perde o gerenciamento baseado em SSH.
Esta nota se baseia nos comandos servidor/cliente SSH do switch Huawei série S e sua saída de log, além dos casos de campo por trás deles. A redação de clientes de terceiros (Xshell, PuTTY, OpenSSH) é citada conforme observada, mas a redação exata pode variar conforme a versão do cliente. Não cobre em profundidade os modos de falha específicos de SFTP/SCP, nem cenários de tunelamento SSH e encaminhamento de porta.
Envie-nos o texto exato na tela — do lado do cliente e do servidor, se tiver ambos — e ajudamos você a localizá-lo no mapa.