ssh_exchange_identification: read: restablecimiento de la conexión por igual

107

Estoy en OS X tratando de ingresar a un servidor ubuntu 12.04. Pude ingresar SSH, hasta que las cosas dejaron de funcionar abruptamente. He leído en línea para usar el -vpara depurar esto. La salida se muestra a continuación. Si ingreso en un cuadro diferente y luego ssh desde ese cuadro al servidor, puedo iniciar sesión. No tengo idea de cómo depurar este problema, pero me gustaría aprender.

$ ssh -v me@server
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
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 *
debug1: Connecting to server [IP] port 22.
debug1: Connection established.
debug1: identity file /Users/me/.ssh/id_rsa type 1
debug1: identity file /Users/me/.ssh/id_rsa-cert type -1
debug1: identity file /Users/me/.ssh/id_dsa type -1
debug1: identity file /Users/me/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: read: Connection reset by peer

Hasta ahora (siguiendo los consejos de los tableros de mensajes) he buscado un archivo de denegación de hosts , pero no hay tal archivo en mi máquina.

$ cat /etc/hosts.deny 
cat: /etc/hosts.deny: No such file or directory

Tengo acceso de administrador en la máquina del cliente pero no en el servidor.

ssh

— bernie2436
fuente

Recomendaría comenzar a sshdescuchar en un puerto alternativo, con salida detallada, y proporcionar la salida cuando intente conectarme a él. $(which sshd) -d -p 23. Si no tiene la capacidad de hacer esto, sus opciones son bastante limitadas. La mejor apuesta es conseguir a alguien que tenga derechos de administrador en el servidor.

— Patrick

¿Podría ser que el administrador en el servidor restringió su acceso por alguna razón? En cualquier caso, podría contactar a esa persona.

— mdpc

12

Los archivos hosts.deny y hosts.allow deben verificarse en el servidor , no en el cliente. Además, se deben verificar los registros del sistema en el servidor . Si tampoco tiene acceso a ellos, puede ponerse en contacto con el administrador del servidor para echar un vistazo.

— ckujau

¿Encontraste una solución? ¿cual fue el problema?

— MeV

2

Era una lista hosts.deny que el administrador completaba con un script automático. Como olvidé mi contraseña en algún momento, tuve algunos intentos fallidos de iniciar sesión, que es cuando mi IP se colocó en la lista de hosts.deny. Esto en cuanto a la productividad de la seguridad entusiasta.

— K.-Michael Aye

25

El cambio abrupto podría ser el resultado de un cambio en el archivo de configuración en la configuración de los servidores sshd, pero usted indica que no puede verificarlo ni modificarlo sin el derecho de administrador. Aún puede intentar lo siguiente si no se puede contactar a los administradores del servidor (a tiempo).

Su registro solo indica la cadena de versión local, debe verificar las versiones de sshdejecución en el servidor y la máquina intermedia.

Si estas versiones difieren (especialmente entre la máquina local y el servidor y menos entre la máquina intermedia y el servidor) puede haber alguna incompatibilidad de negociación, esto ha sucedido antes en ssh. La solución solía ser acortar las entradas de Ciphers, HostKeyAlgorithms y / o MAC, ya sea en la línea de comandos ( ssh -c aes256-ctr, etc.) o en su /etc/ssh/ssh_config.

Debe buscar en la información de depuración (desde la conexión a través del intermediario hasta el servidor) los valores apropiados como argumento para la línea de comando -c/ Ciphers, -o HostKeyAlgorithms/ HostKeyAlgorithmsy -m/ MACsresp. ssh_config cambia.

No he tenido este problema por un tiempo, pero IIRC cuando lo hice fue suficiente para forzar manualmente la configuración de Ciphers y HostKeyAlgorithms, después de lo cual pude actualizar la sshdversión del servidor y el problema desapareció.

— Anthon
fuente

3

En mi caso, el sshdpaquete del servidor se actualizó a una versión más nueva y da como resultado la incompatibilidad con la sshconfiguración actual de mi cliente como usted dijo. Borrar mis viejos ssharchivos de configuración hizo el truco. Esta debería ser la respuesta aceptada.

— chakrit

2

@chakrit, ¿cómo limpiaste tus viejos archivos de configuración ssh?

— Jonathan

@ Jonathan Monté un disco de recuperación para hacerlo.

— chakrit

16

Es posible que haya sido prohibido por fail2bano denyhosts. En tal caso (y también para verificarlo), si no desea molestarse con la asistencia de su proveedor de servidores, debe iniciar sesión en su servidor desde otra dirección IP: por ejemplo, otro servidor, o la conexión a casa de un amigo, o un punto caliente wifi, o usando SSH con TOR.

Una vez que haya iniciado sesión, verifique que su dirección IP aparezca /etc/hosts.deny(en el lado del servidor). Si es así, entonces fail2bano denyhostsdebe ser el culpable.

Consulte las respuestas a esta pregunta para conocer el procedimiento para evitar el denyhostsbloqueo continuo de su dirección. Para fail2banencontrar su ip con iptables -L --line-numbery desbancar su ip iptables -D <chain> <chain number>, verifique los detalles en howtoforge .

Es posible que desee agregar su dirección IP fail2bany denyhostslistas blancas (respectivamente /etc/fail2ban/jail.conf, línea ignoreipy /var/lib/denyhosts/allowed-hostscrearla si es necesario (pero tenga en cuenta que la ruta puede ser diferente en su distribución)) para evitar que el problema vuelva a ocurrir.

— Skippy le Grand Gourou
fuente

9

En el servidor host, elimine el ssh pub.key que se encuentra aquí: ~/.ssh/authorized_keyspara su mac. Luego, tail -f /var/log/auth.logmientras abres otra terminal e intentas ssh nuevamente ssh -v me@server. Si se le solicita una contraseña, hubo un problema con su clave ssh. Si todavía ve la respuesta 'ssh_exchange_identification: read: Connection reset by peer', debería poder identificar cuál es el problema desde la entrada de registro en el archivo '/var/log/auth.log' después de su intento fallido iniciar sesión.

Si aún no pudo conectarse, publique aquí la entrada registrada del archivo de autenticación y revisaré mi respuesta.

— devnull
fuente

No es necesario eliminar la clave SSH en algunos casos. Vaya directamente a tail -f /var/log/auth.log y verifique los intentos recientes.

— Jack Robson

6

Esto puede suceder si tiene varias máquinas en la red con la misma dirección MAC (por ejemplo, si hace una copia de una máquina virtual y olvida cambiar la MAC).

— elCapitano
fuente

4

Estaba recibiendo esto debido a los servidores de nombres de mi ISP /etc/resolv.conf. Estos servidores de nombres a menudo están sobrecargados y si la búsqueda inversa de DNS falla, sshdse cortará la conexión. Resolví el problema usando servidores de nombres más confiables, por ejemplo 8.8.8.8.

— njahnke
fuente

4

Me enfrenté al mismo problema. Abriría la sesión ssh con éxito pero se restablecería después de un tiempo. Cuando intenté conectar la ganancia inmediatamente, recibí el error "Conexión rechazada". cuando depuré la sesión recibí este mensaje en el momento en que se restablecía la conexión

debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: channel 0: free: client-session, nchannels 1                             
debug3: channel 0: status: The following connections are open:                   
  #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)                              

debug3: channel 0: close_fds r 4 w 5 e 6 c -1                                    
Read from remote host 10.x.y.z: Connection reset by peer                    
Connection to 10.x.y.z closed.                                              
debug1: Transferred: stdin 0, stdout 0, stderr 100 bytes in 1029.9 seconds       
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.1                      
debug1: Exit status -1

En este punto me di cuenta de que había un conflicto de dirección IP en la red. Cambié a otra dirección y el problema se resolvió

— David
fuente

2

Votos a favor, ¿qué tiene de malo la respuesta? Todavía puede ser un caso válido para verificar cuando se baja por una lista, simplemente tal vez no sea común entre otros.

— Pysis

@Pysis: respuesta correcta y votada

— Daniel

3

Su registro significa que el lado del servidor desconecta la conexión. Para averiguar el motivo, debe consultar los registros del lado del servidor, deben mostrar el motivo de la desconexión. Casi siempre deberías poder encontrar registros en / var / log / messages

Podría adivinar que, como la conexión se cortó justo después de que el cliente envió el número de versión, el servidor de alguna manera amenaza al cliente como incompatible.

— gena2x
fuente

3

Tuve el mismo problema, pero resultó que la causa era diferente: estaba usando un puerto incorrecto.

En las versiones más nuevas del ssherror dado es Connection refusedo Bad port.

En versiones anteriores el error dado es ssh_exchange_identification: read: Connection reset by peer

Entonces, cuando obtenga dicho error, compruebe si el puerto es correcto.

— Mugoma J. Okomba
fuente

1

Sé que esta pregunta es antigua, pero quería compartir algunos hallazgos que tuve. Compruebe si /var/empty/sshdel servidor tiene la propiedad y los permisos adecuados.

Teníamos un script de chef que se modificó para actualizar algunos permisos de directorio, pero accidentalmente actualicé el directorio debajo del objetivo deseado, cambiando la propiedad de / var a un usuario / grupo de aplicación y cambiando los permisos a 775.

— Andrew Boerema
fuente

1

Como no se ha mencionado explícitamente en una Respuesta, otra forma en que puede aparecer este error es si un servidor de seguridad basado en la red entre usted y el servidor ha decidido bloquear la conexión. El firewall podría haber decidido que había "demasiadas" conexiones desde la IP del sistema OS X, y comenzó a bloquearlo. Todavía no había "demasiadas" conexiones del otro sistema, por lo que estaba permitido.

El último mensaje que recibió del servidor es uno que ocurre incluso antes de comenzar cualquier intento de autenticación, lo que descarta una gran clase de posibilidades que rodean su cuenta, clave o contraseña.

Ejemplos de tales políticas de fuerza bruta de una muestra aleatoria de proveedores son:

— Jeff Schaller
fuente