SSH no funciona desde una computadora específica

Me puedo conectar desde cualquier otra computadora en la LAN, así como externamente. Se conecta bien a otras máquinas que ejecutan SSHD. Cuando intento ssh con verbosidad, obtengo la siguiente lectura:

$ ssh -vvv 192.168.1.9
OpenSSH_6.2p2, OpenSSL 1.0.1e 11 Feb 2013
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.9 [192.168.1.9] port 22.
debug1: Connection established.
debug1: identity file /home/Steven/.ssh/id_rsa type -1
debug1: identity file /home/Steven/.ssh/id_rsa-cert type -1
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/Steven/.ssh/id_dsa" as a RSA1 public key
debug1: identity file /home/Steven/.ssh/id_dsa type 2
debug1: identity file /home/Steven/.ssh/id_dsa-cert type -1
debug1: identity file /home/Steven/.ssh/id_ecdsa type -1
debug1: identity file /home/Steven/.ssh/id_ecdsa-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

¿Alguna idea de lo que podría haber estropeado? No recuerdo haber cambiado en los archivos de configuración SSH, solo agregué algunos usuarios a los grupos para experimentar con los permisos. Incluso cuando trato de no especificar una cuenta (como arriba) todavía se cuelga en "Cadena de versión local SSH-2.0-OpenSSH_6.2" por un minuto antes de dar el error final. Estoy ejecutando Ubuntu Server 12.04 x86, por lo que vale.

Lo que esto significa, en última instancia, es que el servidor SSH en el otro extremo se ha bloqueado o de alguna manera no funciona. Todavía está escuchando en el zócalo, pero no es capaz de realizar un apretón de manos criptográfico.

La única solución es reiniciar el proceso en el lado remoto.

Tuve este mismo problema, lo que encontré fue que mi IP se mantuvo agregada al archivo etc / hosts.deny.

Resolví esto simplemente iniciando sesión en otro servidor VPS, luego conectando ssh al VPS bloqueado y eliminé mi IP (estática) del archivo hosts.deny.

Mi primer intento fue encontrar " ssh_exchange_identification: read: Connection reset by peer" y verificar con el código fuente, pero desafortunadamente no he encontrado ninguno. Entonces, con varios métodos, intenté replicar el mismo problema en mi lado, pero no pude crear el mismo problema en mi lado, como puedes ver a continuación.

Con la raíz sshd_config DenyUsers

Registro del lado del cliente

Permiso denegado, por favor, intente de nuevo

Registro del lado del servidor

2 de julio 02:47:32 servidor sshd [27118]: usuario root de CLIENT_IP no permitido porque aparece en DenyUsers

Con hosts.deny

sshd: CLIENT_IP

Registro de depuración del lado del cliente:

ssh_exchange_identification: conexión cerrada por host remoto

Registro del lado del servidor

2 de julio 02:46:28 servidor sshd [27100]: rechazado la conexión desde CLIENT_IP (CLIENT_IP)

Con PAM negar

Registro del lado del cliente:

Permiso denegado (clave pública, teclado interactivo).

Registro del lado del servidor:

PAM-listfile: usuario rechazado xyz para el servicio ssh

Con cuenta de bloqueo

Registro del lado del cliente:

debug2: enviamos un paquete de contraseña, espere la respuesta debug1: Autenticaciones que pueden continuar: publickey, gssapi-with-mic, contraseña Permiso denegado, intente nuevamente.

Registro del lado del servidor:

2 de julio 02:57:16 servidor sshd [27303]: pam_unix (sshd: auth): error de autenticación; logname = uid = 0 euid = 0 tty = ssh ruser = rhost = CLIENT_IP user = usertest 2 de julio 02:57:17 server sshd [27303]: Error de contraseña para usertest del puerto CLIENT_IP 39431 ssh2 2 de julio 02:57:35 server sshd [27303]: Error de contraseña para la prueba de uso del puerto CLIENT_IP 39431 ssh2

Luego, después de hacer una búsqueda en Google, parece ser este problema porque:

• IP duplicada en su red
• Podría ser su error.

Esto puede suceder si el enrutamiento entre las dos computadoras es diferente. Vale la pena analizar tanto las configuraciones de enrutamiento de los dos puntos finales como los firewalls por los que pasan los paquetes.

Prueba: ssh -2 name@ipossh -2 -l name ip