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

J'ai compilé OpenSSH_6.6p1 sur l'un de nos serveurs. Je peux me connecter via SSH au serveur mis à niveau. Mais je ne peux pas me connecter à d'autres serveurs exécutant OpenSSH_6.6p1 ou OpenSSH_5.8 à partir de cela. Lors de la connexion, j'obtiens une erreur comme ci-dessous.

Read from socket failed: Connection reset by peer

Sur le serveur de destination dans les journaux, je le vois comme ci-dessous.

sshd: fatal: Read from socket failed: Connection reset by peer [preauth]

J'ai essayé de spécifier le cipher_spec [ssh -c aes128-ctr destination-server] comme mentionné ici et j'ai pu me connecter. Comment configurer ssh pour utiliser le chiffrement par défaut? Pourquoi le chiffrement est-il requis ici?

Le problème ressemble à un bogue côté serveur. Lorsque le client envoie la liste des chiffres, 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 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, le serveur ferme la connexion lorsqu'il n'a pas obtenu la liste complète des chiffres à la fois. Lorsque le prochain paquet du client arrive, le serveur envoie une réinitialisation de connexion au client.

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

1. Sur la ligne de commande à l'aide de -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. Utiliser Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbccomme suggéré par Eric devrait fonctionner correctement.

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 en ligne de commande peut être définie dans le fichier de configuration ssh (client).

Voici la ligne pertinente (décommentez juste):

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

Ma façon de le réparer, j'espère que cela aide 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

Modifier sshd_config en ajoutant une valeur

add :  MaxAuthTries 3

Modifier ssh_config en décommentant une valeur

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

Résolution de ce problème en modifiant les autorisations de fichier ci-dessous à 600.

/ etc / ssh / ssh_host_dsa_key
/ etc / ssh / ssh_host_rsa_key
/ etc / ssh / ssh_host_ecdsa_key

A également modifié l'autorisation pour tous les autres fichiers dans '/ etc / ssh /' en 644. Tous les fichiers doivent appartenir à 'root'.

Vous trouverez ci-dessous l'ensemble complet des commandes pour attribuer les autorisations appropriées à tous les fichiers du répertoire '/ etc / ssh':

racine chown: root / etc / ssh / * chmod 644 / etc / ssh / *
chmod 600 / etc / ssh / ssh_host_dsa_key
chmod 600 / etc / ssh / ssh_host_rsa_key
chmod 600 / etc / ssh / ssh_host_ecdsa_key

Mon problème qui avait exactement les mêmes symptômes que vous voyez était dû à des clés d'hôte tronquées. Essayez de les recréer avec:

sudo rm /etc/ssh/ssh_host_*
sudo ssh-keygen -A