.png)
Soynousando hosts.allow
o 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 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 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_config
con 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 sshd
sin dejar que se demonice. El problema en mi caso fue que ninguno de los dos mostraba syslog
nada auth.log
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 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 sshd
el requisito de una ruta absoluta. De lo contrario, obtendrá el siguiente error: sshd re-exec requires execution with an absolute path
. Las -p 10222
marcas sshd
escuchan en ese puerto alternativo, anulando el archivo de configuración; esto es para que no entre en conflicto con sshd
instancias 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 dd
para 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 sshd
configuración.sintener que reiniciar el sshd
en 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 peer
problema 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