STelnet se niega a conectar, Xshell arroja un error de algoritmo, o el aviso de contraseña simplemente vuelve a aparecer en bucle. Cada uno de estos casos tiene detrás una cadena de texto real del lado del cliente, y ese texto ya indica en qué etapa del protocolo de enlace SSH falló realmente. Esta es una referencia caso por caso — el texto exacto, la causa raíz y el comando de corrección para cada uno, extraídos de casos de campo reales en switches.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
Sea lo que sea que muestre el cliente, rara vez es vago por accidente — le está diciendo exactamente en qué etapa del protocolo de enlace se quedó atascado.
Las fallas de inicio de sesión SSH se tratan con demasiada frecuencia como un problema único e indiferenciado, cuando en realidad la propia redacción del cliente ya lo acota. Xshell, PuTTY, OpenSSH en Windows, y el propio cliente stelnet del switch informan las mismas fallas subyacentes de forma distinta — una discrepancia de versión se lee como un reinicio de socket en un cliente y como un error de protocolo limpio en otro — pero por debajo, la falla siempre está en uno de cuatro puntos: la conexión TCP al puerto 22 en sí, la negociación de algoritmos, la confianza de la clave de host, o el intercambio AAA/contraseña.
Lo que sigue está organizado por el reporte literal, no por conjeturas: el texto exacto del lado del cliente, lo que realmente ocurre detrás, y el comando que lo soluciona — quince de los reportes que aparecen constantemente, además de una breve lista de verificación genérica y cinco respuestas de preguntas frecuentes del campo.
Cuatro etapas, en orden estricto — y un reporte de una etapa posterior significa que todo lo anterior ya tuvo éxito.
Ubicar la redacción exacta que está viendo en este mapa le indica de inmediato cuál de los quince reportes siguientes aplica realmente, y descarta muchos de los que no.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
La mayoría de los quince reportes siguientes solo necesitan leerse una vez descartado lo básico.
Un caso de campo ni siquiera es un mensaje de error: STelnet simplemente tarda de diez a quince segundos en iniciar sesión, sin ninguna falla en ningún lado. Esto casi siempre se debe a que el cliente ofrece una clave Diffie-Hellman group-exchange de 8192 bits — cuanto más largo el módulo negociado, más tiempo tarda el switch en calcular la clave compartida, y esa elección la hace el cliente, no el switch. Un cliente distinto, o una longitud negociada más corta, lo soluciona de inmediato; no hay falla que 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 según el texto exacto en pantalla — la causa detrás, y el comando que lo soluciona.
SÍNTOMAEl cliente STelnet reporta: Error: Failed to verify the server's public key, seguido de un aviso para ejecutar ssh client first-time enable, justo después de ingresar el nombre de usuario.
CAUSAEsta es la primerísima conexión de este cliente a este servidor. Sin el acceso de primera vez habilitado, el cliente no tiene ninguna copia guardada de la clave de host del servidor con la cual comparar, por lo que la verificación de confianza falla directamente en lugar de pedir confirmación.
SOLUCIÓNHabilite la autenticación de primera vez en el cliente para que pueda guardar la clave de host en esta primera conexión y verificarla en cada una posterior.
[SwitchA] display this
// confirm ssh client first-time enable is not already present
[SwitchA] ssh client first-time enableSÍNTOMAEl cliente OpenSSH reporta: ssh_rsa_verify: RSA modulus too small: 512 < minimum 768 bits, luego key_verify failed for server_host_key.
CAUSAEl par de claves RSA local del switch se generó con un módulo por debajo de la longitud que los clientes SSH modernos están dispuestos a aceptar — 512 bits, en este caso.
SOLUCIÓNVuelva a generar el par de claves local en el servidor SSH con un módulo más largo.
[SwitchA] rsa local-key-pair create
The range of public key size is (512 ~ 2048).
Input the bits in the modulus[default = 512]:1024SÍNTOMAEl cliente OpenSSH reporta: RSA host key for x.x.x.x has changed and you have requested strict checking, con una advertencia de ataque de intermediario y una línea Offending RSA key que apunta a una línea específica en known_hosts.
CAUSALa clave de host del switch cambió legítimamente — una regeneración de clave, una unidad de reemplazo, un reinicio tras un restablecimiento de fábrica — y el cliente está comparando contra una entrada ahora obsoleta guardada anteriormente.
SOLUCIÓNEn el cliente, elimine la entrada obsoleta de known_hosts para que pueda aprender la nueva clave en la siguiente conexión.
# on the SSH client
rm /root/.ssh/known_hostsSÍNTOMAEl switch actuando como cliente SSH reporta: Error: The number of public keys reached the upper limit(20), luego: Error: Failed to save the server's public key.
CAUSAUn switch que actúa como cliente STelnet guarda la clave de host de cada nuevo servidor SSH al que se conecta por primera vez, y el almacenamiento local tiene un tope de 20 claves de servidor guardadas.
SOLUCIÓNEncuentre una entrada que ya no necesite, elimine su vínculo con el servidor, luego elimine la clave pública del peer subyacente para liberar un espacio.
[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.1SÍNTOMAXshell reporta: Socket error Event: 32 Error: 10053, luego Connection closing...Socket close — antes incluso de ingresar un nombre de usuario o contraseña.
CAUSAEl switch envió un RST TCP, cerrando el socket. En el caso más común, el debugging muestra que el cliente ofreció una cadena de versión SSH-1.x mientras que el switch solo admite SSH-2.0/SSH-1.99, y el paso de coincidencia de versión falló directamente.
SOLUCIÓNFuerce SSH2 en el cliente. Si realmente se deben admitir clientes SSH1 más antiguos, cargue el complemento WEAKEA y habilite la compatibilidad del lado del 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 pluginSÍNTOMALa salida detallada de OpenSSH muestra: debug1: Remote protocol version 1.99, remote software version -, seguido de debug1: no match: -.
CAUSAUna discrepancia en el banner de versión de protocolo entre cliente y servidor impide que el intercambio coincida correctamente.
SOLUCIÓNAlinee ambos lados en SSH2 — es tanto la opción más segura como la predeterminada en el software de switch actual; habilite la compatibilidad ssh1.x solo cuando no haya forma de evitarlo.
SÍNTOMAPuTTY reporta: Couldn't agree a host key algorithm (available: rsa-sha2-512,rsa-sha2-256).
CAUSAEl switch ofreció un conjunto de algoritmos de clave de host para los cuales la lista preferida configurada en PuTTY no incluye ninguna coincidencia.
SOLUCIÓNEn PuTTY, en la configuración de SSH / Kex, fuerce la versión de protocolo SSH preferida a 2 y configure el respaldo para ejecutar siempre la versión 2; si la discrepancia persiste, cargue el complemento WEAKEA en el switch y amplíe allí la lista de algoritmos de clave de host aceptados.
SÍNTOMAXshell muestra un cuadro de diálogo que reporta no matching outgoing encryption algorithm o no matching key exchange algorithm, y el registro del switch anota FailedReason=Failed to negotiate the encryption algorithm.
CAUSALas listas de algoritmos del cliente y del switch para cifrado, HMAC o intercambio de claves no comparten ninguna entrada común — la negociación SSH siempre elige el primer algoritmo que las listas del servidor y del cliente tienen en común, y si no hay ninguno, falla directamente.
SOLUCIÓNAbra la configuración de seguridad SSH del cliente (Conexión > SSH > Seguridad en Xshell) y habilite todas las opciones de cifrado, HMAC e intercambio de claves listadas; compare con lo que el switch realmente admite, y si aún no hay coincidencia, cargue el complemento WEAKEA en el switch para ampliar su propia 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 settingsSÍNTOMAEl switch reporta Error: Failed to connect to the remote host, el OpenSSH de Windows reporta ssh: connect to host x.x.x.x port 22: Connection refused, o Xshell reporta Could not connect to '10.54.4.71' (port 25): Connection failed — y el debugging no muestra absolutamente nada.
CAUSADos causas distintas producen exactamente el mismo síntoma. En V200R020 y versiones posteriores, el switch por defecto no acepta solicitudes de inicio de sesión SSH desde ninguna interfaz hasta que se vincule explícitamente una interfaz de origen. Por separado, el cliente puede simplemente tener el número de puerto incorrecto, o una ACL está vinculada al servidor SSH o a la interfaz de usuario VTY y está descartando silenciosamente la dirección del cliente.
SOLUCIÓNVincule una interfaz de origen del servidor SSH (o todas las interfaces); luego confirme el número de puerto que usa el cliente y verifique tanto ssh server acl como cualquier acl vinculada bajo user-interface vty en busca de una regla que deniegue la dirección del 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 IPSÍNTOMAXshell pide la contraseña, se ingresa la contraseña, y el mismo aviso de contraseña simplemente reaparece — nunca un mensaje de falla, nunca un éxito. El registro muestra FailedReason=User password authentication failed.
CAUSAEl tipo de autenticación predeterminado del usuario SSH se eliminó con undo ssh authentication-type default password, por lo que el proceso SSH nunca reenvía realmente las credenciales a AAA para verificarlas — el debugging confirma que AAA nunca recibe ninguna solicitud.
SOLUCIÓNRestaure password como el tipo de autenticación SSH predeterminado, o configúrelo explícitamente por usuario.
[Switch] ssh authentication-type default password
// or, per user:
ssh user john
ssh user john authentication-type password
ssh user john service-type allSÍNTOMASegún el cliente: el propio switch reporta The connection was closed by the remote host; el OpenSSH de Windows reporta Received disconnect from x.x.x.x port 22:2: The connection is closed by SSH server; IPOP reporta Server sent disconnect message. Los tres aparecen tras varios intentos de contraseña.
CAUSATres contraseñas incorrectas en cinco minutos bloquea ese nombre de usuario durante cinco minutos, y el servidor cierra activamente la conexión en lugar de seguir pidiendo la contraseña. Cada cliente simplemente expresa de forma distinta la misma desconexión del lado del servidor.
SOLUCIÓNConfirme el bloqueo con display local-user state block, luego espere cinco minutos para el desbloqueo automático o elimínelo de inmediato en la vista AAA. Si la cuenta está bloqueada en todas las vías remotas a la vez, nuestra nota de recuperación de bloqueo de inicio de sesión del router cubre el regreso a nivel de consola.
<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-passwordSÍNTOMAEl registro anota: Failed to login. Reason: "The channel configuration is incorrect." — y cada cliente solo reporta un tiempo de espera agotado o conexión rechazada, sin más detalle ni salida de debugging.
CAUSATodos los canales VTY ya están ocupados. El máximo predeterminado es 5 usuarios VTY simultáneos, y una vez agotado, las nuevas sesiones SSH simplemente no pueden asignarse un canal para negociar.
SOLUCIÓNConfirme con display users y display user-interface maximum-vty, luego amplíe el rango VTY y configure la autenticación en las líneas recién disponibles.
<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 sshSÍNTOMAEl registro anota FailedReason=The user's service type was incorrect, o FailedReason=The user type was incorrcet (esa es la ortografía literal en la propia salida de registro del switch) — después de que la contraseña en sí ya fue aceptada.
CAUSAEl usuario SSH existe, pero su service-type no incluye STelnet, o el service-type del usuario local AAA correspondiente está configurado para un método de acceso completamente distinto.
SOLUCIÓNConfigure tanto el service-type del usuario SSH como el del usuario local AAA para incluir SSH explícitamente.
ssh user john
ssh user john authentication-type password
ssh user john service-type all
[Switch-aaa] local-user john service-type sshSÍNTOMAEl registro anota SSH/4/SSH_FAIL con FailedReason=User password authentication failed, pero la cuenta se autentica por RADIUS y la contraseña en sí es correcta.
CAUSAdebugging radius all muestra que los valores de los atributos Login-Service y Service-Type del servidor RADIUS no coinciden con lo que espera un inicio de sesión SSH administrativo — Service-Type debe ser 6 (Administrative), y Login-Service debe incluir el valor que permite SSH.
SOLUCIÓNCorrija los valores de los atributos Login-Service y Service-Type en el propio servidor RADIUS, no en el switch.
[RDS(Evt):] Receive a packet(Code:authentication accept)
[Login-Service] [6] [0] // wrong
[Service-Type] [6] [1] // should be 6 (Administrative)SÍNTOMAEl registro anota SSH_FAIL(s) con FailedReason=User public key authentication failed, aunque el mismo inicio de sesión se completa exitosamente con contraseña momentos después.
CAUSAEl cliente no especificó un método de inicio de sesión por adelantado. SSH intenta la autenticación por clave pública primero de forma predeterminada; cuando el cliente no ha configurado una clave, ese intento falla y se registra, luego el cliente recurre a la autenticación por contraseña, que tiene éxito. No hay forma de suprimir esta línea de registro específica.
SOLUCIÓNNada que corregir — este es el comportamiento esperado cuando se intenta primero la autenticación por clave pública y la autenticación por contraseña es lo que realmente se pretende.
Sacadas directamente del campo — las que vale la pena tener respuesta lista.
Como servidor: display this include-default | include ssh server. Como cliente: display this include-default | include ssh client. Ambos muestran las listas exactas de cifrado, HMAC, intercambio de claves y clave pública vigentes, ya sea que se hayan configurado explícitamente o se hayan dejado por defecto.
El software reciente de los switches se envía sin algoritmos débiles habilitados por defecto por razones de seguridad. Cargue el complemento WEAKEA (install-module en V200, install feature-software WEAKEA en V600), luego deshaga los comandos específicos ssh server/client cipher, hmac, key-exchange y publickey para volver a una lista que incluya las opciones más antiguas y débiles — y vuelva a ejecutar ssh server-source all-interface, ya que V200R020 y versiones posteriores no aceptan conexiones en ninguna interfaz por defecto.
Un switch Huawei que ejecuta stelnet host-ip no desencadena nada hacia el servidor — ni siquiera una conexión TCP — hasta que realmente se escribe el nombre de usuario. El ssh nativo de Windows y Xshell establecen ambos la conexión TCP inmediatamente al iniciar, antes de ingresar cualquier nombre de usuario. Esa sola diferencia explica mucho comportamiento que de otro modo resultaría confuso en el primer aviso.
Un online-fail-record vacío generalmente significa que AAA nunca recibió la solicitud en absoluto, lo que apunta a algo anterior a la autenticación — verifique si el tipo de autenticación SSH predeterminado está configurado, si el debugging muestra que el proceso SSH llega a la etapa de autenticación, y si una ACL de VTY o del servidor SSH está descartando silenciosamente al cliente antes de que llegue tan lejos.
A menudo sí, pero el orden de diagnóstico difiere lo suficiente como para merecer su propio enfoque por capas — vea nuestra nota de diagnóstico SSH de dispositivo AntiDDoS fuera de línea para el desglose de seis capas cuando un dispositivo de seguridad específicamente pierde la gestión basada en SSH.
Esta nota se basa en los comandos servidor/cliente SSH del switch Huawei serie S y su salida de registro, además de los casos de campo que los respaldan. La redacción de clientes de terceros (Xshell, PuTTY, OpenSSH) se cita tal como se observó, pero la redacción exacta puede variar según la versión del cliente. No cubre en profundidad los modos de falla específicos de SFTP/SCP, ni escenarios de tunelización SSH y reenvío de puertos.
Envíenos el texto exacto en pantalla — tanto del lado del cliente como del servidor, si los tiene — y le ayudaremos a ubicarlo en el mapa.