Problema de SSH: error de lectura del socket: restablecimiento de la conexión por igual

23

Puedo SSH en una dirección sin problemas:

OKAY:

ssh user@computerA

pero a la inversa:

ssh user@computerB

Consigo Read from socket failed: Connection reset by peer.

Ni siquiera empiezo a saber dónde buscar para resolver esto.

Alguien tiene alguna pista?

ssh

— boehj
fuente

¿Cuál es su configuración de red? ¿Alguna de las máquinas está detrás de un firewall / enrutador?

— NorTicUs

Ambos se conectaron entre sí a través de un cable Ethernet a través de un enrutador. Han SSH'd en ambas direcciones en el pasado.

— boehj

¿Verificaste que ambos demonios SSH se estén ejecutando? ¿Algo en los registros?

— NorTicUs

Buenas y malas noticias: respondí mi propia pregunta. Lo escribiré a continuación. Gracias por tu ayuda de todos modos.

— boehj

13

comenzar a monitorear el archivo de registro del servidor

tail -f /var/log/auth.log
agregue -v para obtener una salida detallada en el extremo del cliente

ssh user@computerB -v

Esto podría darle más detalles sobre la causa. si faltan las claves rsa y dsa en el servidor, corríjalas de la siguiente manera:

ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_rsa_key
ssh-keygen -t dsa  -f /etc/ssh/ssh_host_dsa_key

— ántrax
fuente

Esto funcionó para mí. Aunque tenía que ser root para ejecutar lo siguiente: ssh-keygen -t dsa -f / etc / ssh / ssh_host_dsa_key

— StarDust

La regeneración de claves definitivamente funciona. En mi caso, estaba cambiando la dirección IP de la máquina después de instalar openssh (y las claves generadas durante la instalación).

— Alfishe

Después de hacer esto, perdí cualquier posibilidad de conectarme a mi servidor. Tuve que pedir la ayuda del proveedor de hosting. Aún esperando su respuesta. Centos 7 con cPanel.

— Tomás González el

8

Reinstalé los bits SSH haciendo:

sudo apt-get --reinstall install openssh-server openssh-client

Esto solucionó todos mis problemas.

— boehj
fuente

8

Podría ser una coincidencia Que el problema dejó de suceder en el momento en que reinstaló ssh no es una garantía hermética de causa y efecto. Por cierto, ¿de qué lado reinstalaste? ¿O ambos? En cualquier caso, "es poco probable que esta pregunta ayude a los futuros visitantes".

— Kaz

5

El método de änthräX es muy útil. ¡Esto funciona para mi!

Básicamente creo que, después de instalar ssh, se necesitan archivos clave.

La única revisión que hice fue usar en rsalugar de rsa1:

ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key 
ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key

Ese método modificado funcionó para mí.

— Alan_04
fuente

Este fue el problema en mi caso. El paquete del servidor ssh con la versión actual de Ubuntu para la máquina Utilite ARM instalada con el síntoma del OP. Después de ejecutar estos dos comandos (que hice como root), finalmente puedo ingresar. Muchas gracias. +1

— James T Snell

1

Es porque de alguna manera los permisos de los archivos dentro /etc/sshhan cambiado ... Así que cambie el permiso de los archivos como en el ejemplo que se muestra a continuación:

utilizar:

chmod 644 ssh_config
chmod 600 moduli

y así...

Finalmente, los permisos de archivo deberían verse como los que se muestran a continuación,

[root@hostname ssh]# ls -latr
total 172

-rw-r--r--.   1 root root   2047 Aug 12  2010 ssh_config
-rw-------.   1 root root 125811 Aug 12  2010 moduli
-rw-------.   1 root root    963 Mar  1 16:02 ssh_host_key
-rw-r--r--.   1 root root    627 Mar  1 16:02 ssh_host_key.pub
-rw-r--r--.   1 root root    382 Mar  1 16:02 ssh_host_rsa_key.pub
-rw-------.   1 root root   1675 Mar  1 16:02 ssh_host_rsa_key
-rw-r--r--.   1 root root    590 Mar  1 16:02 ssh_host_dsa_key.pub
-rw-------.   1 root root    668 Mar  1 16:02 ssh_host_dsa_key
-rw-------.   1 root root   3845 May  7 11:52 sshd_config

Después de cambiar los permisos, intente conectarse desde masilla, debería funcionar bien.

— Joseph Varun
fuente

1

¿Por qué es relevante la masilla? Y considere preguntarle al OP cuáles son los permisos en los archivos antes de avisarle que los cambie.

— Clive van Hilten

Lo siento mucho por publicar la respuesta de manera incorrecta. Ahora aquí está la cosa, durante la instalación de una aplicación alguien cambió los permisos de estos archivos a 777. Esto lo supe al pasar por / var / log / messages (conexión en serie a la máquina). Por lo tanto, cambió los permisos, ¿y adivina qué? Funcionó bien después de eso.

— Varun Joseph

1

Tuvimos un problema similar, pero ocurrió solo al iniciar sesión desde Ubuntu a Solaris. Asegurarse de que todas estas líneas estén presentes en /etc/ssh/ssh_config el host de Ubuntu solucionó el problema (debería encontrar que algunas de estas líneas ya están presentes):

Host *
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
HostKeyAlgorithms ssh-rsa,ssh-dss
MACs hmac-md5,hmac-sha1,hmac-ripemd160

En el caso de Xubuntu, solo necesitaba los dos últimos.

— Philip Kearns
fuente

0

Este mensaje también puede provenir de múltiples intentos de ataques ssh. Si está viendo este mensaje en sus registros, una fuente malintencionada puede estar intentando ingresar en su máquina mediante intentos de contraseña de fuerza bruta.

Para ralentizar los intentos, instale el paquete "fail2ban":

sudo apt-get install fail2ban

Desde la página wiki de fail2ban :

Fail2ban escanea los archivos de registro (por ejemplo, / var / log / apache / error_log) y prohíbe las IP que muestran signos maliciosos: demasiadas fallas de contraseña, búsqueda de vulnerabilidades, etc. Generalmente, Fail2Ban se usa para actualizar las reglas del firewall para rechazar las direcciones IP por un período de tiempo especificado

— Liloulinx
fuente

1

Explique su respuesta con más detalles sobre por qué esto funcionaría

— DnrDevil