SSH: DH_GEX-Gruppe außerhalb des Bereichs

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 user@host.domain.com
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: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,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,rijndael-cbc@lysator.liu.se
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,rijndael-cbc@lysator.liu.se
25 debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
26 debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
27 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
28 debug2: kex_parse_kexinit: none,zlib@openssh.com,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,hmac-sha256@ssh.com
38 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-md5-96,hmac-sha1-96,hmac-sha256,hmac-sha256@ssh.com
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.

— sbrown
quelle

Du liest es richtig. Was um alles in der Welt ist am anderen Ende? Das sieht nicht nach einem herkömmlichen SSH-Server aus.

— Michael Hampton

Keine Ahnung was der Server ist. Wir haben das gleiche Problem mit zwei verschiedenen Anbietern, die beide Banken sind. Keiner der Server identifiziert sich in der Sitzung (was nicht überraschend ist).

— sbrown

Man könnte meinen, Banken wären ein bisschen sicherer, aber leider ...

— Michael Hampton

Die Suche nach "GXSSSHD_Comments" führt zu Kommentaren in verschiedenen SFTP-Client-Foren, die wiederum darauf hindeuten, dass Ihr Server die GXS-MFT- Anwendung ist - sehr unternehmerisch.

— Castaglia

Wenn Sie neueres OpenSSH verwenden möchten, um eine Verbindung zu veralteten Servern herzustellen:

ssh -o KexAlgorithms=diffie-hellman-group14-sha1 -o HostKeyAlgorithms=+ssh-dss my.host.com

Fügen Sie -v hinzu, wenn Sie sehen möchten, was passiert, und -o HostKeyAlgorithms = ssh-dss, wenn es immer noch nicht funktioniert:

ssh -v -o HostKeyAlgorithms=ssh-dss -o KexAlgorithms=diffie-hellman-group14-sha1 my.host.com

Sie können natürlich auch / etc / ssh / ssh_config oder ~ / .ssh / ssh_config bearbeiten und Folgendes hinzufügen:

Host my.host.com *.myinsecure.net 192.168.1.* 192.168.2.*
    HostKeyAlgorithms ssh-dss
    KexAlgorithms diffie-hellman-group1-sha1

https://forum.ctwug.za.net/t/fyi-openssh-to-access-rbs-openssh-7/6069 erwähnt den folgenden Fix auf Mikrotik Routerboards:

/ip ssh set strong-crypto=yes

(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:

GIT_SSH="ssh -oHostKeyAlgorithms=+ssh-dss -oKexAlgorithms=diffie-hellman-group14-sha1" git clone ssh://user@host/path-to-repository

— Dagelf
quelle

dies funktioniert auch für

— sftp

Es scheint, dass Sie diesen Bug getroffen haben .

Ursache

Es wurde eine Änderung am openssh-Paket vorgenommen, das sich mit Diffie-Hellman Group Exchange befasst. Zuvor konnten Schlüssel der Größen 1024 - 8192 ausgetauscht werden. Das Minimum wurde zur Erhöhung der Sicherheit und zur Vermeidung der Sicherheitsanfälligkeit "logjam" auf 1536 angehoben. Bei Verwendung mit einigen ssh-Implementierungen von Drittanbietern, die nur 1024 unterstützen, tritt jedoch ein Fehler auf. Im Idealfall sollte die ssh-Konfiguration oder der Code von Drittanbietern aktualisiert werden, um größere Schlüsselgrößen zu verwenden.

...

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.

KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

— xmar
quelle