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/config
ne 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 sshd
service uniquement), et maintenant le problème a disparu: je peux ssh sur le serveur comme d'habitude.
Réponses:
Les
-cbc
algorithmes 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.)
la source
Vous pouvez mettre à jour votre configuration ssh à partir du fichier situé dans: / etc / ssh / ssh_config
sudo nano /etc/ssh/ssh_config
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
Ctrl + X
. Appuyez sur Entrée pour enregistrer et quitter.la source
créer un fichier dans ~ / .ssh / config et coller sous le contenu
la source