ssh kann nicht verhandeln - es wurde keine passende Schlüsselaustauschmethode gefunden

Ich versuche, mich bei meinem DSL-Router anzumelden, weil ich Probleme mit der Befehlszeile habe. Ich hoffe, den Router neu konfigurieren zu können.

Wenn ich den sshBefehl gebe , passiert Folgendes:

$ 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

Also habe ich mir diesen Stackexchange-Post angesehen und meinen Befehl dahingehend geändert, aber ich habe ein anderes Problem, diesmal mit den Chiffren.

$ 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

Gibt es also einen Befehl, um 3des-cbc Verschlüsselung anzubieten ? Ich bin mir nicht sicher, ob ich 3des dauerhaft zu meinem System hinzufügen möchte.

Gibt es einen Befehl, um die 3des-cbcChiffre zuzulassen ?

Was ist das Problem hier? Es wird nicht nach einem Passwort gefragt.

Dieser bestimmte Fehler tritt auf, während der verschlüsselte Kanal eingerichtet wird. Wenn Ihr System und das ferne System nicht mindestens eine Verschlüsselung gemeinsam haben, muss keine Verschlüsselung vereinbart werden, und es ist kein verschlüsselter Kanal möglich. Normalerweise bieten SSH-Server eine kleine Handvoll verschiedener Chiffren an, um unterschiedliche Clients zu bedienen. Ich bin mir nicht sicher, warum Ihr Server so konfiguriert ist, dass nur 3DES-CBC zulässig ist.

Jetzt ist 3DES-CBC nicht schrecklich. Es ist langsam und bietet weniger Sicherheit als einige andere Algorithmen, aber es ist nicht sofort zerbrechlich, solange die Schlüssel richtig ausgewählt sind. CBC selbst hat einige Probleme, wenn Chiffretext während des Transits geändert werden kann, aber ich vermute stark, dass die resultierende Korruption von SSHs HMAC abgelehnt wird, was die Auswirkungen verringert. Unterm Strich gibt es schlechtere Alternativen als 3DES-CBC und bessere. Gehen Sie jedoch immer vorsichtig vor, wenn Sie sicherheitsrelevante Standardeinstellungen überschreiben, einschließlich der Auswahl von Verschlüsselungs- und Schlüsselaustauschalgorithmen.Diese Standardeinstellungen sind aus einem bestimmten Grund die Standardeinstellungen. Einige ziemlich kluge Köpfe haben sich über die Optionen Gedanken gemacht und festgestellt, dass das, was als Standard ausgewählt wurde, den besten Kompromiss zwischen Sicherheit und Leistung bietet.

Wie Sie herausgefunden haben, können Sie verwenden -c ... (oder -oCiphers=...) verwenden, um anzugeben, welche Verschlüsselung vom Client angeboten werden soll. In diesem Fall -c 3des-cbcerlaubt das Hinzufügen nur 3DES-CBC vom Client. Da dies mit einer vom Server angebotenen Verschlüsselung übereinstimmt, kann ein verschlüsselter Kanal hergestellt werden, und die Verbindung fährt mit der Authentifizierungsphase fort.

Sie können dies auch zu Ihrem persönlichen hinzufügen ~/.ssh/config . Um eine globale Änderung zur Lösung eines lokalen Problems zu vermeiden, können Sie diese in eine HostZeilengruppe einfügen. Zum Beispiel, wenn Ihre SSH-Konfiguration aktuell sagt (Dummy-Beispiel):

Port 9922

Wenn Sie einen globalen Standardport von 9922 anstelle des Standardports von 22 angeben, können Sie eine Hostzeilengruppe für den Host, für den eine spezielle Konfiguration erforderlich ist, und eine globale Hostzeilengruppe für den Standardfall hinzufügen. Das wäre so etwas wie ...

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

Der Einzug ist optional, aber ich finde, dass er die Lesbarkeit erheblich verbessert. Leerzeilen und Zeilen, die mit beginnen# werden ignoriert.

Wenn Sie sich immer (oder meistens) als derselbe Benutzer auf diesem System anmelden, können Sie auch diesen Benutzernamen angeben:

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

Sie müssen keine Host *Zeilengruppe hinzufügen, wenn Ihre ~ / .ssh / config zunächst nichts enthält, da in diesem Fall nur kompilierte oder systemweite Standardeinstellungen (normalerweise von / etc / ssh / ssh_config) verwendet werden gebraucht.

Zu diesem Zeitpunkt reduziert sich die ssh-Befehlszeile zum Herstellen einer Verbindung mit diesem Host auf "Einfach"

$ ssh 10.255.252.1

Alle anderen Benutzer auf Ihrem System und Verbindungen zu allen anderen Hosts von Ihrem System sind von den Änderungen nicht betroffen.

Ok, ich habe die Manpage gelesen und es herausgefunden.

Ich wollte meine Konfigurationsdatei nicht ändern und suchte in der Manpage nach dem Begriff "Chiffre", der mir die -cOption zeigte . Dadurch kann ich den Verschlüsselungstyp angeben. der end befehl lautete dann:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c 3des-cbc enduser@10.255.252.1

Ich bin vor kurzem auf dieses Problem gestoßen, indem ich PuTTY verwendet habe, um eine Verbindung zu einer neueren Version von Ubuntu herzustellen. Es scheint, dass frühere Versionen von PuTTY keine aktualisierten Chiffren hatten. Das Herunterladen der neuesten Version von PuTTY hat das Problem behoben. Das könnte eine andere Lösung sein.

Eine weitere Antwort für MacOSX- und CLI-Befehle (z. B. SFTP) finden Sie in diesem Artikel unter http://www.openssh.com/legacy.html (OpenSSL Legacy Options). Es wurde der Fehler "Konnte nicht verhandeln" angezeigt, der durch Informationen in diesem Artikel behoben wurde, insbesondere durch das Festlegen eines Konfigurationsparameters in der Datei "~ / .ssh / config".

Übrigens, ich habe diesen Fehler erhalten, als mein Ziel-SFTP-Server (nicht unter meiner Verwaltung) TLS 1.0 (SSL-Verschlüsselungsoption) endgültig deaktiviert hat und TLS 1.1 oder 1.2 erfordert.