Wir haben kürzlich einen vom Hersteller bereitgestellten Patch für OpenSSH installiert. Dieser Patch deaktivierte einige Schlüsselaustauschprotokolle als Reaktion auf den jüngsten Logjam-Angriff. Nach der Anwendung dieses Patches haben wir einige Anbieter, mit denen wir keine Dateien über SFTP austauschen konnten, da die Verbindungsaushandlung fehlschlägt (wahrscheinlich aufgrund der veralteten Schlüsselaustauschalgorithmen).
Ich möchte nur ein paar Dinge überprüfen, die wir sehen, bevor ich mit unseren Lieferanten spreche. Hier ist eine SSH-Beispielsitzung mit einem der Problemanbieter (Zeilennummern hinzugefügt):
# ssh -vv [email protected]
01 OpenSSH_6.2p2, OpenSSL 0.9.8j-fips 07 Jan 2009
02 debug1: Reading configuration data /etc/ssh/ssh_config
03 debug1: /etc/ssh/ssh_config line 20: Applying options for *
04 debug2: ssh_connect: needpriv 0
05 debug1: Connecting to host.domain.com [1.2.3.4] port 22.
06 debug1: Connection established.
07 debug1: permanently_set_uid: 0/0
08 debug1: identity file /root/.ssh/id_rsa type -1
09 debug1: identity file /root/.ssh/id_rsa-cert type -1
10 debug1: identity file /root/.ssh/id_dsa type -1
11 debug1: identity file /root/.ssh/id_dsa-cert type -1
12 debug1: identity file /root/.ssh/id_ecdsa type -1
13 debug1: identity file /root/.ssh/id_ecdsa-cert type -1
14 debug1: Enabling compatibility mode for protocol 2.0
15 debug1: Local version string SSH-2.0-OpenSSH_6.2
16 debug1: Remote protocol version 2.0, remote software version GXSSSHD_Comments
17 debug1: no match: GXSSSHD_Comments
18 debug2: fd 3 setting O_NONBLOCK
19 debug1: SSH2_MSG_KEXINIT sent
20 debug1: SSH2_MSG_KEXINIT received
21 debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
22 debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
23 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
24 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
25 debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
26 debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
27 debug2: kex_parse_kexinit: none,[email protected],zlib
28 debug2: kex_parse_kexinit: none,[email protected],zlib
29 debug2: kex_parse_kexinit:
30 debug2: kex_parse_kexinit:
31 debug2: kex_parse_kexinit: first_kex_follows 0
32 debug2: kex_parse_kexinit: reserved 0
33 debug2: kex_parse_kexinit: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256
34 debug2: kex_parse_kexinit: ssh-dss,ssh-rsa
35 debug2: kex_parse_kexinit: aes128-cbc,3des-ctr,aes128-ctr,3des-cbc,blowfish-cbc,arcfour,arcfour128
36 debug2: kex_parse_kexinit: aes128-cbc,3des-ctr,aes128-ctr,3des-cbc,blowfish-cbc,arcfour,arcfour128
37 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-md5-96,hmac-sha1-96,hmac-sha256,[email protected]
38 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-md5-96,hmac-sha1-96,hmac-sha256,[email protected]
39 debug2: kex_parse_kexinit: none,zlib
40 debug2: kex_parse_kexinit: none,zlib
41 debug2: kex_parse_kexinit:
42 debug2: kex_parse_kexinit:
43 debug2: kex_parse_kexinit: first_kex_follows 0
44 debug2: kex_parse_kexinit: reserved 0
45 debug2: mac_setup: found hmac-md5
46 debug1: kex: server->client aes128-ctr hmac-md5 none
47 debug2: mac_setup: found hmac-md5
48 debug1: kex: client->server aes128-ctr hmac-md5 none
49 debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1536<3072<8192) sent
50 debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
51 DH_GEX group out of range: 1536 !< 1024 !< 8192`
Während der Schlüsselaustauschaushandlung tauschen der Client und der Server ihre Listen der unterstützten Algorithmen aus (Zeilen 21 und 33). Sie stimmen zu, in diesem Fall die erste Übereinstimmung zu verwenden, die in den beiden Listen gefunden wurde diffie-hellman-group-exchange-sha1. Nach meinem Verständnis unterstützt dieser Algorithmus einen Bereich von Bitlängen, die der Client und der Server dann aushandeln müssen. Unter normalen Umständen einigen sich der Client und der Server auf eine Bitlänge und tauschen die Schlüssel unter Verwendung eines DH-Strichs aus der moduliDatei aus, z. B. /etc/ssh/moduli(ich weiß, dass dies die letzte Aussage ist) sehr „Laien sprechen“ , aber das ist in etwa die lange und die kurzen von es).
In diesem Fall sehe ich, dass die Aushandlung der Bitlänge fehlschlägt. In Zeile 49 sagt der Client (ich) "Ich unterstütze Bitlängen zwischen 1536 und 8192 und möchte 3072 Bits verwenden." Der Server antwortet jedoch zurück und sagt: "Ich unterstütze nur 1024 Bits." An diesem Punkt gibt der Kunde auf und sagt: "Ich kann nicht mit dir reden." Ist das eine vernünftige Beschreibung dessen, was hier passiert?
Soweit ich weiß, liegt das Problem zu diesem Zeitpunkt vollständig auf dem Server (vorausgesetzt, wir verhandeln keinen schwächeren Algorithmus wie diffie-hellman-group1-sha1). Der Server müsste modifiziert werden, um die größeren Bitlängen während des Schlüsselaustauschprozesses zu unterstützen.
Ich möchte sicherstellen, dass ich das richtig verstehe, bevor ich fortfahre. Input wird geschätzt.
quelle
Antworten:
Wenn Sie neueres OpenSSH verwenden möchten, um eine Verbindung zu veralteten Servern herzustellen:
Fügen Sie -v hinzu, wenn Sie sehen möchten, was passiert, und -o HostKeyAlgorithms = ssh-dss, wenn es immer noch nicht funktioniert:
Sie können natürlich auch / etc / ssh / ssh_config oder ~ / .ssh / ssh_config bearbeiten und Folgendes hinzufügen:
https://forum.ctwug.za.net/t/fyi-openssh-to-access-rbs-openssh-7/6069 erwähnt den folgenden Fix auf Mikrotik Routerboards:
(Dies wird hier vermerkt, da diese Antwort auch bei der Websuche auftaucht, wenn nach einer ähnlichen Fehlermeldung gesucht wird.)
Wenn Sie es über Git verwenden möchten, ohne Ihre ssh_config zu bearbeiten oder den SSH-Server zu aktualisieren:
quelle
Es scheint, dass Sie diesen Bug getroffen haben .
...
Sie finden 3 verschiedene Auflösungen im Link. In Situationen, in denen Sie keine Administratorrechte haben oder zu viel Bürokratie für tiefgreifende Änderungen vorhanden ist, schien es mir die beste Option zu sein, den problematischen Algorithmus loszuwerden, während Sie auf die Verfügbarkeit von SHA-2 auf dem Server warten. Sie können es sogar benutzerbasiert in Ihrer Datei $ HOME / .ssh / config ausführen.
quelle