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

23

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

$ ssh -vvv [email protected]
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: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
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
[email protected]
aes128-ctr
... and there are several more.

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

ssh -vvv -c aes256-cbc [email protected]

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:

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.

lesnik
la source
1
Connexes - unix.stackexchange.com/questions/333728/… - affiche des informations sur la façon de désactiver.
slm
3
J'ai eu le même problème et j'ai trouvé que vous pouvez facilement changer cela dans l'interface Web (car ssh ne fonctionnait pas pour moi ...), mais en allant dans "Terminal -> paramètres avancés" dans le panneau de configuration DSM, et en sélectionnant le profil "élevé" - pour une raison quelconque, j'avais une sélection manuelle activée ... J'espère que c'est quelque chose que j'ai fait et oublié, et pas quelque chose fait par une mise à jour DSM précédente! - les choix sont maintenant aes128-ctr, aes128-gcm, aes192 *, aes256 *, dhge-sha256, curve25519-sha256, hmac-sha2-256
Zak

Réponses:

17

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.)

telcoM
la source
3

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.
Farhan Ar Rafi
la source
1

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

Host *
  SendEnv LANG LC_*
  Ciphers +aes256-cbc
Yash Jagdale
la source