Correction: ssh_exchange_identification & lsquo; connexion fermée par l'hôte distant & rsquo;
Alors que dans de nombreux cas, ssh_exchange_identification: connexion fermée par une erreur d'hôte distant peut être causée par des problèmes liés aux fichiers de configuration hosts.deny et hosts.allow, il y a d'autres choses qui peuvent causer le problème. Si vous lisez ceci, il y a de fortes chances que vous ayez déjà vérifié que ces deux fichiers n'empêchaient pas votre adresse IP d'essayer d'utiliser ssh sur un serveur distant.
En supposant que tel est le cas, vous pourriez alors vous pencher sur un problème de dépendance, un problème lié à la fragmentation de la mémoire ou même un nombre excessif de sessions provenant de clients individuels. La bonne nouvelle est qu'une fois que vous avez réglé le problème, vous ne devriez plus voir l'erreur.
Méthode 1: correction des dépendances manquantes
Si vous avez obtenu la connexion ssh_exchange_identification: fermée par une erreur d'hôte distant uniquement après la mise à jour d'OpenSSL ou de la glibc, vous êtes peut-être en train de rechercher une dépendance manquante. Exécutez sudo lsof -n | grep ssh | grep DEL à partir de la ligne de commande dans cette situation. Cela vous donnera une liste de fichiers ouverts, puis ne recherchera que ceux qui ont été récemment supprimés liés au démon ssh.
Si vous ne récupérez rien, vous pouvez toujours essayer de redémarrer le démon ou le système lui-même. Vous voudrez essayer de redémarrer si un certain nombre d'erreurs vous ont été renvoyées, bien que vous puissiez ignorer en toute sécurité ceux liés aux messages / run / user / 1000 / gvfs car ils sont causés par un problème non lié qui doit faire avec un système de fichiers virtuel.
Vous pouvez également essayer d'utiliser apt-get, pacman ou yum pour mettre à jour vos paquets si vous pensez que les dépendances posent un problème. Si vous êtes sur un système basé sur Debian ou Ubuntu, vous voudrez peut-être essayer la mise à niveau sudo apt-get -f et voir si cela corrige des paquets cassés dont vous pourriez avoir été victime.
Méthode 2: correction de la fragmentation de la mémoire
Si cela n'a pas aidé, vous pourriez avoir un problème du côté hôte de l'équation. Les hôtes qui s'exécutent à l'intérieur d'une machine virtuelle n'ont pas toujours de partition de swap, ce qui peut entraîner une fragmentation de la mémoire. Accédez à l'hôte par d'autres moyens, peut-être physiquement si possible, puis redémarrez tous les services souffrant de problèmes. MySQL, Apache, nginx et d'autres services similaires pourraient être les coupables.
Bien qu'il ne soit pas toujours possible de redémarrer l'hôte, cela peut corriger le problème et peut être une bonne idée si vous avez alterné entre ce message d'erreur et celui qui renvoie une adresse IP. Gardez à l'esprit que si vous avez un accès quelconque au serveur, vous pouvez exécuter la commande vmstat -s et obtenir des statistiques importantes sur la façon dont la mémoire est utilisée même en tant qu'utilisateur régulier dans de nombreux cas.
Méthode 3: rechercher des instances ssh supplémentaires
Sauf cela, vérifiez si les hôtes essaient de se connecter au serveur. Vous avez peut-être dépassé le nombre maximum de sessions ssh sans le savoir. Effacez les anciennes sessions, puis essayez de vous reconnecter. Une façon simple de le faire est d'exécuter la commande who pour voir quels processus utilisateur sont connectés. Vous ne devriez voir qu'un ou deux utilisateurs connectés. S'il y en a plusieurs parallèles, arrêtez les processus utilisateur et essayez de vous reconnecter .
Cela peut arriver si sshd ne peut pas suivre un script qui démarre plusieurs sessions ssh différentes dans une boucle. Si cela vous arrive, ajoutez la commande sleep 0.3 à la boucle pour que le démon sshd ait le temps de suivre.
Méthode 4: trouver la limite de connexion sshd
Des problèmes de connexion comme celui-ci sont particulièrement fréquents lorsque vous essayez d'utiliser ssh pour accéder à un routeur ou à un autre type de commutateur en boîte discret, car le nombre maximum de connexions par défaut est si petit. Bien que vous ne souhaitiez pas vous permettre de surcharger le serveur, vous pouvez voir quel est le paramètre par défaut.
Essayez de l'exécuter 
sur le serveur pour trouver le nombre de connexions que sshd peut gérer. Dans la plupart des cas, le système devrait utiliser par défaut 10 connexions simultanées, ce qui devrait être suffisant pour la plupart des structures de serveur sur lesquelles une majorité d'utilisateurs est susceptible d'avoir besoin d'utiliser ssh régulièrement.
