Correction de ssh_exchange_identification – connexion fermée par l’hôte distant

Lorsque vous utilisez le client SSH, vous pouvez obtenir un message d’erreur « SSH_exchange_identification : connection closed by remote host ».Si vous voulez trouver des solutions à ce problème, vous pouvez lire cet article de Techquack.Voici quelques solutions réalisables.

Lorsque vous utilisez le client SSH pour vous connecter à un serveur, vous pouvez rencontrer le problème « SSH_exchange_identification : connection closed by remote host ».Ce problème peut avoir plusieurs causes, comme des problèmes avec les fichiers de configuration hosts. deny et hosts. allow.

Voyons comment résoudre le problème « SSH _exchange_identification ».

Qu’est-ce qui amène l’hôte à fermer la connexion « ssh_exchange_identification » ?

Bien que dans de nombreux cas, l’erreur « ssh_exchange_identification : Connection closed by remote host » peut être causé par des problèmes avec les fichiers de configuration hosts. deny et hosts. allow, le problème peut avoir d’autres causes.Si vous lisez ceci, vous avez probablement déjà vérifié que ces deux fichiers ne bloquent pas votre adresse IP lorsque vous essayez d’utiliser ssh sur un serveur distant.

Dans ce cas, il peut s’agir d’un problème de dépendance, de fragmentation de la mémoire ou même d’un nombre excessif de sessions de clients individuels.La bonne nouvelle est qu’une fois le problème résolu, vous ne devriez plus voir cette erreur.

Cette erreur indique que l’hôte distant a soudainement interrompu la connexion.Il s’agit d’une erreur courante que les utilisateurs obtiennent lorsqu’ils essaient de se connecter à des serveurs SSH.La cause principale de cette erreur peut être liée aux fichiers de configuration hosts. deny et hosts. allow.

Pour résoudre le problème de fermeture de la connexion ‘ssh_exchange_identification’ de l’hôte

Vérifier les dépendances manquantes

1. Cette erreur se produit généralement après une mise à jour de Glibc ou d’OpenSSL et le serveur ne peut pas être redémarré.
2. Alors que de nombreuses distributions peuvent installer une mise à jour de Glibc ou d’OpenSSL sans avoir à redémarrer, votre distribution peut ne pas appartenir à la même catégorie.
3. Si vous savez que la mise à jour de la Glibc est installée, utilisez lsof pour voir où dans le SSHD les fichiers sont ouverts.
4. Si vous utilisez Ubuntu ou Debian, utilisez la commande update pour obtenir et installer les nouveaux paquets.Cela vous aidera à résoudre tous les problèmes qui se sont posés en raison de paquets cassés.

Vérifier les sessions SSH supplémentaires

1. Il est possible que des utilisateurs aient dépassé le nombre maximal de sessions SSH sans le savoir.
2. Essayez de supprimer les anciennes sessions, puis reconnectez-vous au serveur.
3. Vous ne devriez voir qu’un ou deux utilisateurs connectés à un moment donné.Pour vérifier si plusieurs instances SSH fonctionnent, utilisez la commande « Who ».
4. S’il y a plus de deux utilisateurs connectés, terminez les processus utilisateur un par un.
5. Reconnectez-vous au serveur via SSH et voyez si la situation s’est améliorée.

Ce problème se produit lorsque SSH ne peut pas suivre un script qui exécute plusieurs sessions SSH à la suite.Vous pouvez également retarder une session SSH en utilisant la commande « Sleep ».

Vérifiez si vos empreintes digitales/clés sont endommagées.

1. Si le problème persiste, vérifiez si les empreintes digitales ou les clés sont endommagées.Ceci est particulièrement important si vous avez installé ces fichiers manuellement.
2. Essayez de supprimer l’empreinte digitale côté serveur dans le client ~/.ssh/known_hosts et réessayez.
3. Lorsque vous vous reconnecterez, vous serez invité à accepter l’ID hôte.Acceptez et continuez.
4. Cette erreur peut également se produire si les fichiers /etc/ssh/*key* sont supprimés et que le SSHD n’est pas redémarré.Vérifiez le répertoire de configuration SSH pour les fichiers de clés.

Vérifiez le démarrage du serveur

Cette erreur peut également se produire si votre serveur est très chargé.

1. Vérifiez si le serveur dispose de suffisamment de ressources pour accomplir la tâche, ou s’il fait l’objet d’une attaque par force brute.
2. Essayez d’augmenter le nombre de connexions que le SSHD peut établir pour résoudre le problème.

L’erreur ssh_exchange_identification : connexion fermée par un hôte distant est une erreur courante et peut se produire en raison de dépendances manquantes ou de clés corrompues.Suivez les étapes décrites dans cet article pour résoudre les problèmes liés au client SSH.

Questions fréquemment posées

Pourquoi la connexion SSH est-elle fermée ?

L’erreur « connexion fermée par l’hôte distant » est fréquente, mais peu de gens semblent en connaître la cause.Certains indiquent que les fichiers /etc/hosts. allow et /etc/hosts. deny en sont la cause, d’autres disent qu’il peut s’agir d’une défaillance matérielle, de la configuration de sshd ou de mises à jour défectueuses de Glibc.

Que signifie « connexion fermée depuis l’hôte distant » ?

Ce message indique que la charge de Git Fusion dépasse la valeur « MaxStartups » définie dans le fichier sshd_config.Ajustez ce paramètre pour résoudre ce problème ; nous recommandons une valeur minimale de 100.Le fichier sshd_config est généralement situé dans le répertoire /etc/ssh/sshd_config.

Comment réparer le message « Connexion réinitialisée via peer-to-peer » ?

1. Quelle est la cause de l’erreur SSH « Connection reset by peer » ?
2. Vérifiez les fichiers hosts. deny et hosts. allow.Comment modifier le fichier hosts.deny ?Comment modifier le fichier hosts. allow.
3. Vérifiez si fail2ban bloque votre adresse IP.
4. Vérifiez le fichier sshd_config.

Comment puis-je empêcher la désactivation de SSH ?

Allez dans Paramètres > Configuration > SSH . Il y a une section appelée Paramètres SSH, vérifiez l’option SSH keepalive.Le problème devrait alors disparaître.