ssh_exchange_identification: connection cerrada por el host remoto (no usando hosts.deny)

No estoy usando hosts.allow o hosts.deny , aún más SSH funciona desde mi máquina de Windows (misma computadora portátil, disco duro diferente) pero no mi máquina Linux.

ssh -vvv root@host -p port da:

 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 de Windows todo funciona bien, así que revisé los loggings de security y las líneas allí son idénticas, el server trata las dos "máquinas" diferentes, no diferentes, y ambas están permitidas a través de la authentication de key pública.

Entonces eso lleva a la conclusión de que esto debe ser un problema con mi 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 configuration 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 permissions parecen estar bien (lo mismo en el server). También se intentó sin configurar /etc/ssh/ssh_config con el mismo resultado, excepto por la gran cantidad de autoconfiguraciones que se realizan en el cliente y que terminan con el mismo error.

Si ha descartado factores "externos", el siguiente set de pasos generalmente ayuda a networkingucirlo. Entonces, aunque esto no responde directamente a su pregunta, puede ayudar a rastrear la causa del error.

Solución de problemas de sshd

Lo que generalmente encuentro muy útil en estos casos es iniciar sshd sin dejar que se daemonize. El problema en mi caso fue que ni syslog ni auth.log mostraron nada significativo.

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 post de error me permitió ver lo que está mal y arreglarlo. Ninguno de los files de logging contenía esta salida.

NB: al less en Ubuntu, el $(which sshd) es el mejor método para satisfacer los requisitos sshd de una ruta absoluta. De lo contrario, obtendrá el siguiente error: sshd re-exec requires execution with an absolute path . El -p 10222 hace que sshd escuche en ese puerto alternativo, anulando el file de configuration, esto es para que no entre en conflicto con la ejecución de instancias sshd . 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 en la búsqueda de problemas, ya sean de authentication o de otro tipo. Para get una salida muy detallada a stdout , use $(which sshd) -Ddddp 10222 (tenga en count el dd agregado para boost la verbosidad). Para más bondad de debugging, verifique man sshd .

Descubrí que este error se debió a que se excedieron las sesiones ssh en el server. Encontré los hosts tratando de conectar y maté todas las sesiones de todos los clientes. El problema se resolvió después de aclarar todas las sesiones.

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

En tal caso, puede get cualquiera de los posts:

 ssh_exchange_identification: read: Connection reset by peer 

o:

 Connection closed by aaa.bbb.ccc.ddd 

dependiendo de cuán lejos llegue el host antes de que se resquebraje.

Si la causa aparente es la fragmentación de la memory, la solución es acceder al server por otros medios y reiniciar algunos de los services pertinentes. He descubierto 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. En su defecto, reinicie el host.

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

Es una falla estúpida, pero podría ser realmente tu problema.

Me encontré con el ssh_exchange_identification: read: Connection reset by peer problem en un script que inicia 16 o más sesiones ssh en un bucle. sshd aparentemente no puede seguir el ritmo; agregar un breve descanso 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 

O puede que haya hecho lo que hice, anoche, y eliminó / var / empty. Aparentemente ese directory y sus permissions son esenciales para el funcionamiento de sshd y no rehará el directory cuando se reinicie /etc/init.d/sshd no podrá reiniciarse y nada del sistema le dirá por qué.

Encontré el problema al ejecutar sshd en primer plano:

 # /usr/sbin/sshd -Dd Missing privilege separation directory: /var/empty/sshd 

La reconstrucción de los directorys resolvió el problema en mi caso:

 drwxr-xr-x. root root /var/empty drwx--x--x. root root /var/empty/sshd 

Nota para los progtwigdores de Linux: cosas importantes en /var/empty … ¿realmente?

Primero lo primero; telnet a la dirección IP del host para verificar si el puerto 22 está realmente escuchando (abierto) en ese host:

 telnet xxxx 22 

(De lo contrario, puede conectar un cable de console para iniciar session)

En mi caso, no funcionaba y conecté un cable de console para iniciar session. Una vez que inicié session, descubrí que las 5 líneas VTY estaban ocupadas en ese host (un enrutador Cisco).

Limpié conexiones antiguas que estaban colgadas allí para liberar las líneas VTY, funcionó. Agregué el command "exec-timeout 15" debajo de las líneas VTY. Luego quité el cable de la console.

Lección:

Asegúrese de establecer un time de espera de 5-10 minutos en todos sus dispositivos (si no se detecta actividad).