ssh Kann nicht verhandeln: "Keine passende Chiffre gefunden", lehnt cbc ab

23

Ich versuche, auf eine entfernte Maschine zu sshen, der Versuch schlägt fehl:

$ ssh -vvv admin@192.168.100.14
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: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
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

Soweit ich die letzte Zeichenfolge des Stammes verstehen, der Server bietet eine der folgenden vier Verschlüsselungsalgorithmen zu verwenden: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc. Sieht so aus, als ob mein ssh-Client keinen von ihnen unterstützt, sodass der Server und der Client keine weiteren Verhandlungen führen können.

Mein Client unterstützt jedoch alle vorgeschlagenen Algorithmen:

$ ssh -Q cipher
3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
rijndael-cbc@lysator.liu.se
aes128-ctr
... and there are several more.

Und wenn ich den Algorithmus so explizit spezifiziere:

ssh -vvv -c aes256-cbc admin@192.168.100.14

Ich kann mich erfolgreich beim Server anmelden.

Meine ~/.ssh/configenthält keine chiffrierbezogenen Anweisungen (tatsächlich habe ich sie vollständig entfernt, aber das Problem bleibt bestehen).

Warum können Client und Server ohne meine ausdrücklichen Anweisungen nicht entscheiden, welche Verschlüsselung verwendet werden soll? Der Client versteht, dass der Server dies unterstützt aes256-cbc. Der Client versteht, dass er es selbst verwenden kann. Warum nicht einfach?

Einige zusätzliche Hinweise:

Vor einiger Zeit (ungefähr einem Monat) gab es kein solches Problem. Ich habe seitdem keine ssh-Konfigurationsdateien mehr geändert. Ich habe zwar installierte Pakete aktualisiert.
Es gibt eine Frage, die ein sehr ähnlich aussehendes Problem beschreibt, aber es gibt keine Antwort auf meine Frage: ssh kann nicht verhandeln - es wurde keine passende Schlüsselaustauschmethode gefunden

UPDATE: Problem behoben

Wie telcoM erklärte, liegt das Problem beim Server: Es werden nur die veralteten Verschlüsselungsalgorithmen vorgeschlagen. Ich war sicher, dass Client und Server nicht veraltet sind. Ich habe mich beim Server angemeldet (übrigens ist es Synology, aktualisiert auf die neueste verfügbare Version) und das überprüft /etc/ssh/sshd_config. Die allererste (!) Zeile dieser Datei lautete:

Ciphers aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc

Das ist sehr seltsam (die Tatsache, dass die Zeile an erster Stelle in der Datei steht). Ich bin mir sicher, dass ich die Datei noch nie zuvor berührt habe. Allerdings habe ich die Zeile geändert:

Ciphers aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc

den server neu gestartet (habe nicht herausgefunden, wie man den sshdservice nur neu startet), und jetzt ist das problem weg: ich kann ssh auf den server wie gewohnt.

ssh openssh synology

— lesnik
quelle

1

Related - unix.stackexchange.com/questions/333728/… - zeigt Informationen zum Deaktivieren an.

— SLM

3

Ich hatte das gleiche Problem und stellte fest, dass Sie dies leicht über die Weboberfläche ändern können (da ssh bei mir nicht funktioniert hat ...), aber gehen Sie zu "Terminal -> Erweiterte Einstellungen" in der DSM-Systemsteuerung und wählen Sie die "hochkarätig" - aus irgendeinem Grund wurde dort eine manuelle Auswahl aktiviert ... Ich hoffe, das habe ich getan und vergessen, und nicht, was ein vorheriges DSM-Update getan hat! - Die Auswahlmöglichkeiten sind jetzt aes128-ctr, aes128-gcm, aes192 *, aes256 *, dhge-sha256, curve25519-sha256, hmac-sha2-256

— Zak

16

Die -cbcAlgorithmen haben sich als anfällig für Angriffe erwiesen. Aus diesem Grund lehnen aktuelle Versionen von OpenSSH diese Algorithmen jetzt standardmäßig ab: Derzeit sind sie noch verfügbar, wenn Sie sie benötigen. Wie Sie jedoch festgestellt haben, müssen Sie sie explizit aktivieren.

Ursprünglich, als die Sicherheitslücke entdeckt wurde (Ende 2008, vor fast 10 Jahren!), Wurden diese Algorithmen aus Gründen der Kompatibilität nur an das Ende der Prioritätenliste gesetzt, aber jetzt hat ihre Abwertung in SSH eine Phase erreicht, in der sich diese Algorithmen befinden standardmäßig deaktiviert. Laut dieser Frage in Cryptography.SE hat dieser Verfallsschritt bereits im Jahr 2014 stattgefunden.

Bitte denken Sie daran, Ihren SSH-Server nach Möglichkeit zu aktualisieren . (Wenn es sich um eine Firmware-basierte Implementierung handelt, prüfen Sie, ob aktualisierte Firmware für Ihre Hardware verfügbar ist.)

— telcoM
quelle

2

Sie können Ihre ssh-Konfiguration über die Datei unter / etc / ssh / ssh_config aktualisieren

Starten Sie ein Terminal.
Fügen Sie die Zeile in das Terminal ein: sudo nano /etc/ssh/ssh_config
Geben Sie Ihr Passwort ein. Drücken Sie Enter. Die SSH-Konfigurationsdatei wird angezeigt.
Entkommentiere die Zeile: Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
Drücken Sie Ctrl + X. Drücken Sie die Eingabetaste, um zu speichern und zu beenden.

— Farhan Ar Rafi
quelle

1

Erstelle eine Datei in ~ / .ssh / config und füge sie unter dem Inhalt ein

Host *
  SendEnv LANG LC_*
  Ciphers +aes256-cbc

— Yash Jagdale
quelle