ssh_exchange_identification: lire: réinitialisation de la connexion par l'homologue
Je suis sur OS X essayant de faire ssh dans un serveur ubuntu 12.04. J'ai pu SSH - jusqu'à ce que les choses cessent brusquement de fonctionner. J'ai lu en ligne pour utiliser le -v pour déboguer cela. La sortie est illustrée ci-dessous. Si je ssh dans une autre boîte, puis ssh de cette boîte au serveur, je peux me connecter. Je n'ai aucune idée de comment déboguer ce problème mais j'aimerais apprendre.
$ ssh -v me@server
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug1: Connecting to server [IP] port 22.
debug1: Connection established.
debug1: identity file /Users/me/.ssh/id_rsa type 1
debug1: identity file /Users/me/.ssh/id_rsa-cert type -1
debug1: identity file /Users/me/.ssh/id_dsa type -1
debug1: identity file /Users/me/.ssh/id_dsa-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
Jusqu'à présent (sur les conseils des babillards électroniques), j'ai cherché un fichier hosts deny - mais il n'y en a pas sur ma machine.
$ cat /etc/hosts.deny
cat: /etc/hosts.deny: No such file or directory
J'ai un accès administrateur sur la machine cliente mais pas sur le serveur.
La modification abrupte pourrait être le résultat d'une modification du fichier de configuration sur la configuration des serveurs sshd, mais vous indiquez que vous ne pouvez pas vérifier ou modifier cela sans le droit d'administrateur. Vous pouvez toujours essayer ce qui suit si les administrateurs du serveur ne peuvent pas être atteints (à temps).
Votre journal indique uniquement la chaîne de version locale, vous devez vérifier les versions de sshd en cours d'exécution sur le serveur et la machine intermédiaire.
Si ces versions diffèrent (en particulier entre la machine locale et le serveur et moins entre la machine intermédiaire et le serveur), il peut y avoir une incompatibilité de négociation, cela cela s'est déjà produit dans ssh. Auparavant, la solution consistait à raccourcir les entrées Ciphers, HostKeyAlgorithms et/ou MAC, soit sur la ligne de commande (ssh -c aes256-ctr, etc.) ou dans votre /etc/ssh/ssh_config.
Vous devez rechercher dans les informations de débogage (de la connexion via l'intermédiaire au serveur) les valeurs appropriées comme argument pour le -c/Ciphers, -o HostKeyAlgorithms/HostKeyAlgorithms et -m/MACs ligne de commande resp. ssh_config change.
Je n'ai pas eu ce problème moi-même depuis un certain temps, mais l'IIRC quand je l'ai fait a été suffisant pour forcer manuellement le paramètre Ciphers et HostKeyAlgorithms, après quoi j'ai pu mettre à jour la version sshd du serveur et le problème a disparu.
Vous avez peut-être été banni par fail2ban ou denyhosts. Dans un tel cas (et aussi pour le vérifier), si vous ne voulez pas vous soucier de l'assistance de votre fournisseur de serveur, vous devez vous connecter à votre serveur à partir d'une autre adresse IP: par ex. un autre serveur, ou la connexion à domicile d'un ami, ou un hot spot wifi, ou en utilisant SSH avec TOR.
Une fois connecté, vérifiez que votre adresse IP apparaît bien dans /etc/hosts.deny (côté serveur). Si oui, alors fail2ban ou denyhosts doit être le coupable.
Voir les réponses à cette question pour la procédure pour empêcher denyhosts de bloquer votre adresse en continu. Pour fail2ban trouvez votre ip avec iptables -L --line-number et libérez votre ip avec iptables -D <chain> <chain number>, vous vérifiez les détails sur howtoforge .
Vous voudrez peut-être ajouter votre adresse IP à fail2ban et denyhosts listes blanches (respectivement /etc/fail2ban/jail.conf, ligne ignoreip et /var/lib/denyhosts/allowed-hosts, créez-le si nécessaire (mais attention, le chemin peut être différent sur votre distribution)) pour éviter que le problème ne se reproduise.
Sur le serveur hôte, supprimez le ssh pub.key situé ici: ~/.ssh/authorized_keyspour votre mac. Alors tail -f /var/log/auth.log pendant que vous ouvrez un autre terminal et essayez à nouveau de ssh ssh -v me@server. Si vous êtes invité à entrer un mot de passe, il y a eu un problème avec votre clé ssh. Si vous voyez toujours la réponse "ssh_exchange_identification: read: Connection reset by peer", vous devriez être en mesure d'identifier le problème à partir de l'entrée de journal dans le fichier "/var/log/auth.log" après l'échec de votre tentative ouvrir une session.
Si vous ne parvenez toujours pas à vous connecter, postez l'entrée enregistrée dans le fichier d'authentification ici et je réviserai ma réponse.
Cela peut se produire si vous avez plusieurs machines sur le réseau avec la même adresse MAC (par exemple, si vous faites une copie d'une machine virtuelle et oubliez de changer le MAC).
J'étais confronté au même problème. J'ouvrirais la session ssh avec succès mais elle serait réinitialisée après un certain temps. Lorsque j'essayais de connecter immédiatement le gain, j'obtenais l'erreur "Connexion refusée". quand j'ai débogué la session, j'ai reçu ce message au moment où la connexion était réinitialisée
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 1
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 1
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 1
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)
debug3: channel 0: close_fds r 4 w 5 e 6 c -1
Read from remote Host 10.x.y.z: Connection reset by peer
Connection to 10.x.y.z closed.
debug1: Transferred: stdin 0, stdout 0, stderr 100 bytes in 1029.9 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.1
debug1: Exit status -1
À ce stade, j'ai réalisé qu'il y avait un conflit d'adresse IP sur le réseau. J'ai changé d'adresse et le problème a été résolu
Votre journal signifie que côté serveur interrompt la connexion. Pour en connaître la raison, vous devez consulter les journaux côté serveur, ils doivent indiquer la raison de la déconnexion. Vous devriez presque toujours pouvoir trouver des journaux dans/var/log/messages
Je pourrais deviner que, comme la connexion a chuté juste après que le client a envoyé le numéro de version, le serveur menace en quelque sorte le client comme incompatible.
J'obtenais cela en raison des serveurs de noms de mon FAI dans /etc/resolv.conf. Ces serveurs de noms sont souvent surchargés et si la recherche DNS inversée échoue, sshd interrompra la connexion. J'ai résolu le problème en utilisant des serveurs de noms plus fiables, par exemple 8.8.8.8.
J'ai eu le même problème mais il s'est avéré que la cause était différente: j'utilisais un mauvais port.
Sur les versions plus récentes de ssh l'erreur indiquée est Connection refused ou Bad port.
Sur les anciennes versions, l'erreur indiquée est ssh_exchange_identification: read: Connection reset by peer
Ainsi, lorsque vous obtenez une telle erreur, vérifiez si le port est correct.
Puisqu'il n'a pas été mentionné explicitement dans une réponse, une autre façon dont cette erreur peut apparaître est si un pare-feu basé sur le réseau entre vous et le serveur a décidé de bloquer la connexion. Le pare-feu aurait pu décider qu'il y avait "trop" de connexions depuis l'IP du système OS X, et a commencé à le bloquer. Il n'y avait pas encore "trop" de connexions de l'autre système, et donc c'était autorisé.
Le dernier message que vous avez reçu du serveur est celui qui se produit avant même de commencer toute tentative d'authentification, ce qui exclut une grande classe de possibilités entourant votre compte, votre clé ou votre mot de passe.
Des exemples de telles politiques de force brute à partir d'un échantillon aléatoire de fournisseurs sont:
- CloudFlare: Comment utiliser la limitation de débit pour me protéger contre les attaques par force brute?
- F5: Configuration de la protection contre les attaques par force brute
- FortiNet: création personnalisée IPS pour détecter un taux de motif - exemple pour détecter une attaque par force brute
- Palo Alto: Empêcher les attaques par force brute
- Sonicwall: Comment bloquer les attaques Brute Force et Dictionary avec SRA
Je sais que cette question est ancienne, mais je voulais partager certaines conclusions que j'avais. Vérifier si /var/empty/sshd sur le serveur possède la propriété et les autorisations appropriées.
Nous avions un script de chef qui a été modifié pour mettre à jour certaines autorisations de répertoire, mais par inadvertance mis à jour le répertoire sous la cible prévue, en changeant la propriété de/var en un utilisateur/groupe d'application et en changeant les autorisations en 775.
J'ai rencontré cette erreur exacte en essayant de me connecter à tous mes hôtes distants via l'option de pont Wi-Fi sur mon Android appareil (Huawei P30 Pro). Lorsque j'ai utilisé l'option de partage de connexion USB pour partager la même connexion Internet, aucun problème.
Absolument rien d'autre n'a changé dans la configuration ou les options SSH sur le client ou les serveurs.
TL; DR: parfois, vous ne pouvez rien faire.