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 sshcommande, voici ce qui se passe:

$ ssh enduser@10.255.252.1

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 pour cela, mais j'ai un problème différent, cette fois avec les chiffres.

$ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 enduser@10.255.252.1

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

existe-t-il une commande pour proposer le 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-cbcchiffrement?

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

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. Il est lent et offre 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 qui en résulte serait rejetée par le HMAC de SSH, ce qui réduirait 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, l'ajout -c 3des-cbcn'autorise que 3DES-CBC du client. Étant donné que 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 profil personnel ~/.ssh/config. Pour éviter d'apporter un changement global pour résoudre un problème local, vous pouvez le mettre dans une Hoststrophe. Par exemple, si votre configuration SSH indique actuellement (exemple factice):

Port 9922

en spécifiant un port par défaut global 9922 au lieu du port 22 par défaut, vous pouvez ajouter une strophe hôte pour l'hôte qui a besoin d'une configuration spéciale et une strophe hôte 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é. Les lignes vides et les lignes commençant par #sont ignorées.

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 une Host *strophe s'il n'y avait rien dans votre ~ / .ssh / config pour commencer, car 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é.

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

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é l' -coption; 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 enduser@10.255.252.1

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.

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.