ssh Impossible de négocier: «aucun chiffrement correspondant trouvé», rejette cbc

J'essaye de ssh sur la machine distante, la tentative échoue:

$ ssh -vvv admin@192.168.100.14
OpenSSH_7.7p1, OpenSSL 1.0.2o  27 Mar 2018
.....
debug2: ciphers ctos: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
debug2: ciphers stoc: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos: 
debug2: languages stoc:
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: rsa-sha2-512
Unable to negotiate with 192.168.100.14 port 22: no matching cipher found. Their offer: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc

Pour autant que je comprends la dernière chaîne du journal, les offres de serveur à utiliser un des 4 algorithmes de chiffrement suivants: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc. Il semble que mon client ssh ne prenne en charge aucun d'entre eux, donc le serveur et le client ne sont pas en mesure de négocier davantage.

Mais mon client prend en charge tous les algorithmes suggérés:

$ ssh -Q cipher
3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
rijndael-cbc@lysator.liu.se
aes128-ctr
... and there are several more.

Et si je spécifie explicitement l'algorithme comme ceci:

ssh -vvv -c aes256-cbc admin@192.168.100.14

Je peux me connecter avec succès au serveur.

My ~/.ssh/configne contient aucune directive liée au chiffrement (en fait, je l'ai complètement supprimée, mais le problème persiste).

Alors, pourquoi le client et le serveur ne peuvent pas décider quel chiffre utiliser sans mes instructions explicites? Le client comprend que le serveur prend en charge aes256-cbc, le client comprend qu'il peut l'utiliser lui-même, pourquoi ne pas simplement l'utiliser?

Quelques notes supplémentaires:

• Il n'y a pas eu un tel problème il y a quelque temps (environ un mois). Depuis, je n'ai changé aucun fichier de configuration ssh. J'ai cependant mis à jour les packages installés.

• Il y a une question qui décrit un problème d'apparence très similaire, mais il n'y a pas de réponse à ma question: ssh incapable de négocier - aucune méthode d'échange de clé correspondante trouvée

MISE À JOUR: problème résolu

Comme l'explique telcoM, le problème vient du serveur: il ne suggère que les algorithmes de chiffrement obsolètes. J'étais sûr que le client et le serveur ne sont pas périmés. Je me suis connecté au serveur (au fait, c'est Synology, mis à jour vers la dernière version disponible), et j'ai examiné le /etc/ssh/sshd_config. La toute première (!) Ligne de ce fichier était:

Ciphers aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc

C'est très étrange (le fait que la ligne soit très première dans le fichier), je suis sûr que je n'ai jamais touché le fichier auparavant. Cependant, j'ai changé la ligne en:

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

redémarré le serveur (n'a pas compris comment redémarrer le sshdservice uniquement), et maintenant le problème a disparu: je peux ssh sur le serveur comme d'habitude.

Les -cbcalgorithmes se sont révélés vulnérables à une attaque. Par conséquent, les versions à jour d'OpenSSH rejetteront désormais ces algorithmes par défaut: pour l'instant, ils sont toujours disponibles si vous en avez besoin, mais comme vous l'avez découvert, vous devez les activer explicitement.

Initialement, lorsque la vulnérabilité a été découverte (fin 2008, il y a près de 10 ans!), Ces algorithmes n'étaient placés qu'à la fin de la liste des priorités pour des raisons de compatibilité, mais maintenant leur dépréciation dans SSH a atteint une phase où ces algorithmes sont désactivé par défaut. Selon cette question dans Cryptography.SE , cette étape de dépréciation était déjà en cours en 2014.

Veuillez considérer cela comme un doux rappel pour mettre à jour votre serveur SSH , si possible. (S'il s'agit d'une implémentation basée sur un micrologiciel, vérifiez si un micrologiciel mis à jour est disponible pour votre matériel.)

Vous pouvez mettre à jour votre configuration ssh à partir du fichier situé dans: / etc / ssh / ssh_config

1. Lancez un terminal.
2. Collez la ligne dans le terminal: sudo nano /etc/ssh/ssh_config
3. Tapez votre mot de passe. Appuyez sur Entrée. Le fichier de configuration SSH sera affiché.
4. Décommentez la ligne: Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
5. Appuyez sur Ctrl + X. Appuyez sur Entrée pour enregistrer et quitter.

créer un fichier dans ~ / .ssh / config et coller sous le contenu

Host *
  SendEnv LANG LC_*
  Ciphers +aes256-cbc