web-dev-qa-db-fra.com

ssh incapable de négocier - aucune méthode d'échange de clés correspondante trouvée

J'essaie de me connecter à mon routeur DSL, car j'ai des problèmes avec le courrier en ligne de commande. J'espère pouvoir reconfigurer le routeur.

Lorsque je donne la commande ssh, voici ce qui se passe:

$ ssh [email protected]

Unable to negotiate with 10.255.252.1 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

alors j'ai regardé ce post stackexchange , et modifié ma commande en ceci, mais j'ai un problème différent, cette fois avec les chiffres.

$ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 [email protected]

Unable to negotiate with 10.255.252.1 port 22: no matching cipher found. Their offer: 3des-cbc

existe-t-il une commande pour offrir 3des-cbc chiffrement? Je ne suis pas sûr de 3des, comme si je veux l'ajouter en permanence à mon système.

Existe-t-il une commande pour autoriser le 3des-cbc chiffre?

Quel est le problème ici? Ce n'est pas demander un mot de passe.

ssh
39
j0h

Cette erreur particulière se produit pendant la configuration du canal crypté. Si votre système et le système distant ne partagent pas au moins un chiffre, il n'y a pas de chiffre sur lequel se mettre d'accord et aucun canal chiffré n'est possible. Habituellement, les serveurs SSH offrent une petite poignée de chiffrements différents afin de répondre aux différents clients; Je ne sais pas pourquoi votre serveur serait configuré pour n'autoriser que 3DES-CBC.

Maintenant, 3DES-CBC n'est pas terrible. C'est lent et il fournit moins de sécurité que certains autres algorithmes, mais il n'est pas immédiatement cassable tant que les clés sont sélectionnées correctement. CBC lui-même a quelques problèmes lorsque le texte chiffré peut être modifié en transit, mais je soupçonne fortement que la corruption résultante serait rejetée par le HMAC de SSH, réduisant ainsi l'impact. En bout de ligne, il y a des choix pires que 3DES-CBC, et il y en a de meilleurs. Cependant, soyez toujours prudent lorsque vous remplacez les valeurs par défaut liées à la sécurité, y compris les choix d'algorithmes de chiffrement et d'échange de clés. Ces valeurs par défaut sont les valeurs par défaut pour une raison; certaines personnes assez intelligentes ont dépensé un peu de puissance cérébrale en considérant les options et ont déterminé que ce qui a été choisi comme valeurs par défaut offre la meilleure sécurité globale par rapport au compromis entre les performances.

Comme vous l'avez découvert, vous pouvez utiliser -c ... (ou -oCiphers=...) pour spécifier le chiffrement à offrir du côté client. Dans ce cas, ajouter -c 3des-cbc n'autorise que 3DES-CBC du client. Comme cela correspond à un chiffrement proposé par le serveur, un canal chiffré peut être établi et la connexion passe à la phase d'authentification.

Vous pouvez également l'ajouter à votre _ ~/.ssh/config. Pour éviter d'apporter une modification globale pour résoudre un problème local, vous pouvez le placer dans une strophe Host. Par exemple, si votre configuration SSH indique actuellement (exemple factice):

Port 9922

en spécifiant un port par défaut global de 9922 au lieu du 22 par défaut, vous pouvez ajouter une strophe Host pour l'hôte qui a besoin d'une configuration spéciale et une strophe Host globale pour le cas par défaut. Cela deviendrait quelque chose comme ...

Host 10.255.252.1
    Ciphers 3des-cbc
    KexAlgorithms +diffie-hellman-group1-sha1
Host *
    Port 9922

L'indentation est facultative, mais je trouve qu'elle améliore considérablement la lisibilité. Lignes vides et lignes commençant par # sont ignorés.

Si vous vous connectez toujours (ou principalement) en tant que même utilisateur sur ce système, vous pouvez également spécifier ce nom d'utilisateur:

Host 10.255.252.1
    Ciphers 3des-cbc
    KexAlgorithms +diffie-hellman-group1-sha1
    User enduser
Host *
    Port 9922

Vous n'avez pas besoin d'ajouter un Host * strophe s'il n'y avait rien dans votre ~/.ssh/config pour commencer, comme dans ce cas, seules les valeurs par défaut compilées ou à l'échelle du système (généralement à partir de/etc/ssh/ssh_config) seraient utilisées.

À ce stade, la ligne de commande ssh pour se connecter à cet hôte se réduit à simplement

$ ssh 10.255.252.1

et tous les autres utilisateurs de votre système, ainsi que les connexions à tous les autres hôtes de votre système, ne sont pas affectés par les modifications.

52
a CVn

Ok j'ai lu la page de manuel et je l'ai compris.

Je ne voulais pas modifier mon fichier de configuration, et j'ai donc cherché le terme "chiffrement" dans la page de manuel qui m'a montré le -c option; cela me permet de spécifier le type de cryptage. la commande de fin était alors:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c 3des-cbc [email protected]
30
j0h

J'ai récemment rencontré ce problème en utilisant PuTTY pour me connecter à une version plus récente d'Ubuntu. Il semble que les versions antérieures de PuTTY n'avaient pas de chiffrement mis à jour. Le téléchargement de la dernière version de PuTTY a donc résolu le problème. Cela pourrait être une autre solution.

3
Trent Three

Autre réponse pour les composants MacOSX et CLI (SFTP, par exemple): reportez-vous à cet article @ http://www.openssh.com/legacy.html (OpenSSL Legacy Options). J'obtenais une erreur cohérente de "impossible de négocier" qui a été résolue par les informations contenues dans cet article, en particulier la définition d'un paramètre de configuration dans le fichier "~/.ssh/config".

BTW, j'ai eu cette erreur lorsque mon serveur SFTP de destination (pas sous mon administration) a finalement désactivé TLS 1.0 (option de cryptage SSL) et nécessite TLS 1.1 ou 1.2.

1
Charlie L