Me he estado conectando a un servidor remoto a través de mi Mac durante aproximadamente un mes. Sin embargo, recientemente intenté conectarme usando ssh dylan@MY_IP y recibí este mensaje.
ssh_exchange_identification: read: Connection reset by peer
También obtuve información de diagnóstico...
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to {MY IP{ [MY IP] port 22.
debug1: Connection established.
debug1: identity file /Users/watson/.ssh/id_rsa type -1
debug1: identity file /Users/watson/.ssh/id_rsa-cert type -1
debug3: Incorrect RSA1 identifier
debug3: Could not load "/Users/watson/.ssh/id_dsa" as a RSA1 public key
debug1: identity file /Users/watson/.ssh/id_dsa type 2
debug1: identity file /Users/watson/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
Después de investigar un poco, probé lo siguiente...
- Reinicié mi enrutador
- Borré mi archivo "known_hosts"
- Eliminé mi archivo "known_hosts"
- Liberé y renové mi DHCP
- También lo intenté desde otro dispositivo (Windows) usando Putty con un error.
Tenga en cuenta que no he realizado ningún cambio en el servidor para inhibir esta comunicación.
Además, no estoy seguro de si esto causaría problemas, pero me he conectado mediante su nombre de dominio y su IP.
Además, pude conectarme exitosamente desde otra dirección IP.
Sé que este es un problema importante con muchos recursos disponibles, pero muchas de las soluciones no funcionaron ni vi ningún tipo de resolución para nadie.
Actualizar
Lo forcé al protocolo 1. En lugar de "Conexión restablecida por igual", ahora aparece "Conexión cerrada por host remoto". Ejecutarlo con información de depuración revelada:
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to MY_IP [MY_IP] port 22.
debug1: Connection established.
debug1: identity file /Users/watson/.ssh/identity type -1
debug1: identity file /Users/watson/.ssh/identity-cert type -1
ssh_exchange_identification: Connection closed by remote host
Respuesta1
Así es como resolví el error "ssh_exchange_identification: Conexión cerrada por host remoto" al conectarme a un servidor SSH.
Recibí este error al intentar conectarme a una máquina Linux integrada, después de descomprimir un paquete en la raíz. Se reemplazaron muchos archivos de la biblioteca, incluido libssl.
Intentando conectar:
chetic@ubuntu:~$ ssh -v [email protected]
OpenSSH_6.2p2 Ubuntu-6ubuntu0.3, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to SC [192.168.1.100] port 22.
debug1: Connection established.
debug1: identity file /home/delaval/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/delaval/.ssh/id_rsa-cert type -1
debug1: identity file /home/delaval/.ssh/id_dsa type -1
debug1: identity file /home/delaval/.ssh/id_dsa-cert type -1
debug1: identity file /home/delaval/.ssh/id_ecdsa type -1
debug1: identity file /home/delaval/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2p2 Ubuntu-6ubuntu0.3
ssh_exchange_identification: read: Connection reset by peer
Buscar en Google solo parecía sugerir verificar hosts.deny y hosts.allow, pero mi máquina de destino no tenía dichos archivos.
Después de reiniciar (según la sugerencia de Karthik), sshd no se estaba ejecutando. Intenté iniciar sshd manualmente en el objetivo:
# sshd
OpenSSL version mismatch. Built against 1000002f, you have 1000105f
Reemplacé /usr/lib/libssl.a con la versión original, inicié sshd y todo volvió a la normalidad. En mi caso, el problema fue causado por una versión incorrecta en el paquete que descomprimí originalmente en la raíz.
Respuesta2
Recibí el mismo error (pero desde cualquier máquina, incluida la máquina problemática a través de ssh localhost).
Comenzó cuando migré el perfil de un usuario; es decir, después de copiar archivos como root, luego ejecuté comandos comochown -R username /Users/username/Destop
de todos modos, no estoy totalmente seguro de por qué el propietario de /var/empty se cambió a nombre de usuario, pero sshdefinitivamente debe /var/emptyser propiedad de root (de lo contrario, obtendrá ssh_exchange_identification: read: Connection reset by peer):
sudo chown root /var/empty
Respuesta3
Esto no es un problema con su máquina local, sino un problema en el lado del servidor. Podría habermúltiples factorescausando este problema:
- Cambios en la configuración de /etc/hosts.allow o /etc/hosts.deny en el servidor remoto.
- Carga pesada del servidor.
En el pasado, cuando tuve estos problemas, hice una de dos cosas, en el siguiente orden:
- Modifique /etc/hosts.allow como se menciona en el artículo anterior. (y reinicie el servidor SSH)
- Si /etc/hosts.allow ya está como se requiere, simplemente reinicie el servidor SSH (¡y tenga cuidado al hacer esto!)
- Si el reinicio no funciona, regenere las claves del servidor y reinicie el servidor SSH (esto es arriesgado, ya que cada usuario que inicie sesión en esta máquina recibirá un error indicando que el servidor ha cambiado las claves).
La mayoría de las veces, 1 resuelve el problema, pero en algunos casos he tenido que hacer 2. No he podido resolverlo.por quéese es el caso, solo que ha funcionado. Quizás tenga algo que ver con la forma en que se presenta la clave, o quizás se corrompió de alguna manera; no estoy seguro. Pero lo que sí sé es que el error tiene totalmente que ver con el servidor y la forma en que se produce el protocolo de enlace cuando se configura la conexión SSH.
Respuesta4
Ciertamente es un error, ssh funciona con una de mis máquinas pero no con la otra. Lo resolví, sigue estos.
- Genere un token de acceso sin fecha de caducidad y seleccione todas las opciones disponibles.
- Elimine las claves SSH existentes.
- Clona el repositorio con https en lugar de ssh.
- Utilice el nombre de usuario pero utilice el token de acceso generado en lugar de la contraseña.
alternativamente, puede configurar el control remoto en http usando este comando en el repositorio existente y usar este comando git remoto set-url originhttps://gitlab.com/[nombre de usuario]/[nombre-repo].git