Reinstalé una máquina virtual (CentOS7) y ahora aparece este error. La máquina virtual tiene dos adaptadores que se encuentran en subredes diferentes.
bastante divertidossh funcionó bien en una subreddespués de corregir la advertencia MITM esperada.
ssh -v muestra:
OpenSSH_8.0p1, OpenSSL 1.1.1c 28 May 2019
debug1: Reading configuration data /home/user/.ssh/config
debug1: /home/user/.ssh/config line 6: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolving "foreman" port yy
debug2: ssh_connect_direct
debug1: Connecting to foreman [xxx.xxx.xxx.xxx] port yy.
debug1: Connection established.
debug1: identity file /home/sam/.ssh/id_rsa type 0
debug1: identity file /home/sam/.ssh/id_rsa-cert type -1
debug1: identity file /home/sam/.ssh/id_dsa type -1
debug1: identity file /home/sam/.ssh/id_dsa-cert type -1
debug1: identity file /home/sam/.ssh/id_ecdsa type -1
debug1: identity file /home/sam/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/sam/.ssh/id_ed25519 type -1
debug1: identity file /home/sam/.ssh/id_ed25519-cert type -1
debug1: identity file /home/sam/.ssh/id_xmss type -1
debug1: identity file /home/sam/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.0
kex_exchange_identification: read: Connection reset by peer
He intentado
- Reiniciando
- eliminando el archivo conocido_hosts
- comprobado /etc/ssh/ssh_config en el cliente (sin desviación de la versión del mantenedor)
- marcado /etc/ssh/sshd_config en el servidor (sin desviación de la versión del mantenedor)
- deteniendo el firewall
- Permisos comprobados en .ssh/ y Authorized_keys.
- lista negra y lista blanca marcadas (no hay nada allí, solo comentarios) (hosts.deny|hosts.allow)
No estoy seguro de si es relevante, pero el cliente ejecuta Arch Linux.
Entonces, nuevamente para aclarar,
el servidor tiene dos direcciones IP 172.xxx y 192.xxx. ssh funciona para 172.xxx pero no para 192.xxx.
Respuesta1
Para mí, eso suena como un problema de enrutamiento o un problema con las máscaras de red. He visto casos con una configuración similar, donde la pila de red intentó usar la interfaz incorrecta para los paquetes salientes, es decir, donde los paquetes salientes paraambosLas subredes se enrutaron a través de la interfaz para elprimerosubred.
Entonces, lo primero que debe probar es si puede hacer ping a otra máquina encadade las subredes de laservidor, y viceversa. Para que el proceso de prueba sea menos propenso a errores, debe configurar elotromáquinas (clientes) para usar únicamenteunoDirección IP (de lo contrario, la prueba podría fallar debido a una configuración incorrecta delotromáquinas, lo que sería engañoso).
Lo siguiente sería una mirada profunda a la salida route -nen el servidor y en los clientes. Quizás eso ya muestre la causa del problema. ¿Le importaría publicar ese resultado?
Además, el resultado de ifconfig -asería útil (de nuevo en el servidor y en los clientes); eventualmente nos gustaría entender sus máscaras de red.
Al publicar esos resultados, creo que no es necesario ofuscar las direcciones IP siempre que sean del rango privado. La ofuscación per se puede ser propensa a errores, haciendo imposible el análisis.
Si decide publicar esos resultados (edite su pregunta en consecuencia en lugar de usar comentarios para eso, porque los resultados pueden ser largos), lo revisaré e intentaré descubrir qué está sucediendo.
Respuesta2
Recibí este error en una situación ligeramente diferente. En mi caso, el servidor ssh no se instaló en primer lugar, y el servicio de instalación e inicio directo solucionó el problema.
El mensaje principal es que este tipo de error ocurre si no se sirve ssh en el puerto/ip/interfaz, ya sea debido a la instalación o configuración.