GNU/Linux >> Tutoriels Linux >  >> Linux

Problèmes SSH :Échec de la lecture à partir du socket :réinitialisation de la connexion par l'homologue

Solution 1 :

Le problème ressemble à un bogue côté serveur. Lorsque le client envoie la liste des chiffrements, le serveur openssh s'attend probablement à pouvoir lire la liste en un seul appel système.

Si la liste des chiffrements pris en charge est plus longue que ce qui peut être transmis dans un seul paquet, le serveur peut obtenir moins d'octets lors du premier appel que prévu. Le comportement correct sur le serveur serait d'effectuer un autre appel pour obtenir le reste des octets. Mais d'après la description du problème, il apparaît que le serveur ferme la connexion lorsqu'il n'a pas obtenu la liste complète des chiffrements à la fois. Lorsque le prochain paquet du client arrivera, le serveur enverra une réinitialisation de la connexion au client.

Configurer le client pour utiliser une liste plus courte de chiffrements permettrait alors de contourner le bogue. Le client openssh recherchera la liste des chiffrements aux endroits suivants :

  1. Sur la ligne de commande en utilisant -c cipher_spec ou -o Ciphers=cipher_spec
  2. Dans ~/.ssh/config en spécifiant Ciphers cipher_spec dans la section hôte appropriée ou avant le premier hôte.
  3. Dans /etc/ssh/ssh_config en utilisant le même format que ~/.ssh/config
  4. Une liste par défaut intégrée au client au moment de la compilation.

Les deux fichiers de configuration sont respectivement des paramètres par utilisateur et à l'échelle du système. Utilisation de Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc comme Eric l'a suggéré devrait fonctionner correctement.

Solution 2 :

Vous pouvez spécifier le chiffrement dans le fichier de configuration ssh (/etc/ssh/ssh_config ou similaire, dépend de $PREFIX etc). Toute option que vous transmettez au client ssh sur la ligne de commande peut être définie dans le fichier de configuration ssh (client).

Voici la ligne correspondante (décommentez-la simplement) :

#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc

Solution 3 :

Ma façon de le réparer, j'espère que cela aidera quelqu'un :

# Recreate host keys
sudo rm /etc/ssh/ssh_host_*
sudo ssh-keygen -A

# Re-install SSh
sudo apt-get --reinstall install openssh-server openssh-client

Modifiez sshd_config en ajoutant une valeur

add :  MaxAuthTries 3

Modifiez ssh_config en décommentant une valeur

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc

Linux
  1. Ssh :"erreur lors de la lecture de la longueur de la réponse à partir du socket d'authentification" ?

  2. Empêcher Tmux de démarrer sur Ssh ?

  3. Démarrer le serveur Vino Vnc à partir du client Ssh ?

  4. "Réinitialisation de la connexion par un pair" - erreur lors de l'accès à un système CentOS/RHEL avec un utilisateur spécifique uniquement

  5. Linux :y a-t-il une lecture ou une réception à partir du socket avec un délai d'attente ?

Comment réparer ssh_exchange_identification :lire :erreur de connexion réinitialisée par un pair

Comment puis-je lire les entrées du clavier de l'hôte lorsque je suis connecté via SSH ?

sshfs Connexion réinitialisée par un pair avec un fichier d'identification

Empêcher la connexion ssh d'imprimer motd depuis le client ?

Initialisera 1 à partir d'une session ssh distante (via VPN) tuera ma connexion ssh

Que peut-on apprendre sur un utilisateur d'une tentative SSH infructueuse ?