SSH ne fonctionne pas à partir d'un ordinateur spécifique

Je peux me connecter depuis n'importe quel autre ordinateur du LAN, ainsi qu'en externe. Il se connecte très bien aux autres machines exécutant SSHD. En essayant ssh avec verbosité, j'obtiens la lecture suivante:

$ 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

Une idée de ce que j'aurais pu gâcher? Je ne me souviens pas avoir changé dans les fichiers de configuration SSH, ajoutant seulement quelques utilisateurs à des groupes pour expérimenter avec les autorisations. Même lorsque j'essaie de ne pas spécifier de compte (comme ci-dessus), il se bloque toujours à "Chaîne de version locale SSH-2.0-OpenSSH_6.2" pendant une minute avant de donner l'erreur finale. J'utilise Ubuntu Server 12.04 x86, pour ce que ça vaut.

En fin de compte, cela signifie que le serveur SSH à l'autre extrémité est tombé en panne ou ne fonctionne pas d'une manière ou d'une autre. Il écoute toujours sur le socket, mais il n'est pas capable d'effectuer une négociation cryptographique.

La seule solution est de redémarrer le processus du côté distant.

J'ai eu ce même problème, ce que j'ai trouvé était mon IP keept ajouté au fichier etc / hosts.deny.

J'ai résolu ce problème en me connectant simplement à un autre serveur VPS, puis en connectant ssh au VPS bloqué et en supprimant mon adresse IP (domestique statique) du fichier hosts.deny.

Ma première tentative a été de trouver " ssh_exchange_identification: read: Connection reset by peer" et de recouper avec le code source, mais malheureusement je n'en ai pas trouvé. Donc, avec plusieurs méthodes, j'ai essayé de reproduire le même problème de mon côté, mais incapable de créer le même problème de mon côté, comme vous pouvez le voir ci-dessous.

Avec sshd_config DenyUsers root

Journal côté client

Autorisation refusée, veuillez réessayer

Journal côté serveur

2 juillet 02:47:32 serveur sshd [27118]: la racine utilisateur de CLIENT_IP n'est pas autorisée car répertoriée dans DenyUsers

Avec hosts.deny

sshd: CLIENT_IP

Journal de débogage côté client:

ssh_exchange_identification: Connexion fermée par l'hôte distant

Journal côté serveur

2 juillet 02:46:28 serveur sshd [27100]: refus de connexion de CLIENT_IP (CLIENT_IP)

Avec PAM deny

Journal côté client:

Autorisation refusée (publickey, clavier interactif).

Journal côté serveur:

PAM-listfile: utilisateur xyz refusé pour le service ssh

Avec compte de verrouillage

Journal côté client:

debug2: nous avons envoyé un paquet de mot de passe, attendez la réponse debug1: authentifications pouvant continuer: publickey, gssapi-with-mic, mot de passe Autorisation refusée, veuillez réessayer.

Journal côté serveur:

2 juillet 02:57:16 serveur sshd [27303]: pam_unix (sshd: auth): échec d'authentification; logname = uid = 0 euid = 0 tty = ssh ruser = rhost = CLIENT_IP user = usertest 2 juil 02:57:17 server sshd [27303]: Échec du mot de passe pour usertest depuis le port CLIENT_IP 39431 ssh2 2 juil 02 02:57:35 server sshd [27303]: Échec du mot de passe pour le test d'utilisateur à partir du port CLIENT_IP 39431 ssh2

Ensuite, après avoir fait une recherche Google, il semble que ce problème soit dû à:

• IP en double dans votre réseau
• C'est peut-être son bug.

Cela peut se produire si le routage entre les deux ordinateurs est différent. Il vaut la peine d'examiner les configurations de routage des deux points de terminaison ainsi que les pare-feu traversés par les paquets.

Essayez: ssh -2 name@ipoussh -2 -l name ip