ssh_exchange_identification: Conexión cerrada por host remoto (sin usar hosts.deny)

ssh_exchange_identification: Conexión cerrada por host remoto (sin usar hosts.deny)

Soynousando hosts.allowo hosts.deny, además, SSH funciona desde mi máquina con Windows (misma computadora portátil, disco duro diferente) pero no desde mi máquina Linux.

ssh -vvv root@host -p portda:

OpenSSH_6.6, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to host [host] port <port>.
debug1: Connection established.
debug1: identity file /home/torxed/.ssh/id_dsa type -1
debug1: identity file /home/torxed/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6
ssh_exchange_identification: read: Connection reset by peer

En la máquina con Windows, todo funciona bien, así que verifiqué los registros de seguridad y las líneas allí son idénticas, el servidor trata a las dos "máquinas" diferentes de la misma manera y ambas están permitidas mediante autenticación de clave pública.

Entonces eso lleva a la conclusión de que esto debe ser un problema con mi computadora portátil ArchLinux local... pero ¿qué?

[torxed@archie ~]$ cat .ssh/known_hosts 
[torxed@archie ~]$ 

Entonces ese no es el problema...

[torxed@archie ~]$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 

No hay conflictos con la configuración del firewall (por ahora).

[torxed@archie ~]$ ls -la .ssh/
total 20
drwx------  2 torxed users 4096 Sep  3  2013 .
drwx------ 51 torxed users 4096 May 11 11:11 ..
-rw-------  1 torxed users 1679 Sep  3  2013 id_rsa
-rw-r--r--  1 torxed users  403 Sep  3  2013 id_rsa.pub
-rw-r--r--  1 torxed users  170 May 11 11:21 known_hosts

Los permisos parecen estar bien (lo mismo en el servidor). También lo intenté sin configurar /etc/ssh/ssh_configcon el mismo resultado, excepto por una gran cantidad de configuración automática en el cliente que termina con el mismo error.

Respuesta1

Publicado originalmente en Pregúntale a Ubuntu

Si ha descartado algún factor "externo", el siguiente conjunto de pasos suele ayudar a reducirlo. Entonces, si bien esto no responde directamente a su pregunta, puede ayudar a rastrear la causa del error.

Solución de problemassshd

Lo que encuentro generalmente muy útil en estos casos es comenzar sshdsin dejar que se demonice. El problema en mi caso fue que ninguno de los dos mostraba syslognada auth.logsignificativo.

Cuando lo inicié desde la terminal obtuve:

# $(which sshd) -Ddp 10222
/etc/ssh/sshd_config line 8: address family must be specified before ListenAddress.

¡Mucho mejor! Este mensaje de error me permitió ver qué estaba mal y solucionarlo. Ninguno de los archivos de registro contenía este resultado.

NÓTESE BIEN:al menos en Ubuntu, $(which sshd)es el mejor método para satisfacer sshdel requisito de una ruta absoluta. De lo contrario, obtendrá el siguiente error: sshd re-exec requires execution with an absolute path. Las -p 10222marcas sshdescuchan en ese puerto alternativo, anulando el archivo de configuración; esto es para que no entre en conflicto con sshdinstancias potencialmente en ejecución. Asegúrese de elegir un puerto libre aquí.

Finalmente: conéctese al puerto alternativo ( ssh -p 10222 user@server).

Este método me ha ayudado muchas veces a encontrar problemas, ya sean problemas de autenticación u otros tipos. Para obtener una salida realmente detallada stdout, use $(which sshd) -Ddddp 10222(tenga en cuenta el agregado ddpara aumentar la detalle). Para obtener más información sobre la depuración, consulte man sshd.


La principal ventaja de este método es que permite comprobar la sshdconfiguración.sintener que reiniciar el sshden el puerto predeterminado.NormalmenteEsto no debería interferir con las conexiones SSH existentes, pero lo he visto. Entonces, esto permite validar el archivo de configuración antes de, potencialmente, cortar el acceso a un servidor remoto (por ejemplo, tengo eso para algunos VPS e incluso para servidores físicos donde necesito pagar más para obtener acceso fuera de banda). a la máquina).

Respuesta2

También puede tener un host cuya memoria esté tan fragmentada que no pueda asignar a una página una memoria contigua para bifurcar el proceso de alojamiento de una sesión SSH.

En tal caso, puede recibir cualquiera de los mensajes:

ssh_exchange_identification: read: Connection reset by peer

o:

Connection closed by aaa.bbb.ccc.ddd

dependiendo de qué tan lejos llegue el anfitrión antes de salir del apuro.

Si la causa aparente es la fragmentación de la memoria, la solución es acceder al servidor por otros medios y reiniciar algunos de los servicios pertinentes. Descubrí que Apache y MySQL son los culpables de las máquinas virtuales, ya que las máquinas virtuales no tienen una partición de intercambio. De lo contrario, reinicie el host.

Respuesta3

Por las dudas, porque a mí me pasó esto. ¡Asegúrate de tener sshd ejecutándose en el host!

Es un fracaso estúpido, pero podría ser realmente tu problema.

Respuesta4

Me encontré con el ssh_exchange_identification: read: Connection reset by peerproblema en un script que inicia 16 o más sesiones ssh en un bucle. sshd aparentemente no puede seguir el ritmo; agregando un sueño corto (claramente unsolución alterna... :D votantes negativos) resolvió mi problema:

for i in $(seq 32)
do
    ssh -f root@$HOST "./test_server -p $(expr $BASE_PORT + $i)" > svr${i}.out
    # for > 8 connections, ssh has ssh_exchange_identification issues
    sleep 0.1
done

información relacionada