SSH: DH_GEX-Gruppe außerhalb des Bereichs

SSH: DH_GEX-Gruppe außerhalb des Bereichs

Wir haben kürzlich einen vom Anbieter bereitgestellten Patch für OpenSSH angewendet. Dieser Patch hat als Reaktion auf den jüngsten Logjam-Angriff einige Schlüsselaustauschprotokolle deaktiviert. Nach der Anwendung dieses Patches konnten wir mit einigen Anbietern keine Dateien mehr über SFTP austauschen, da die Verbindungsverhandlung fehlschlug (wahrscheinlich aufgrund der veralteten Schlüsselaustauschalgorithmen).

Ich möchte nur ein paar Dinge überprüfen, die wir sehen, bevor ich mit unseren Anbietern spreche. Hier ist ein Beispiel für eine SSH-Sitzung 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üsselaustauschverhandlung tauschen Client und Server ihre Listen der unterstützten Algorithmen aus (Zeilen 21 und 33). Sie vereinbaren, die erste Übereinstimmung zu verwenden, die in den beiden Listen gefunden wird, in diesem Fall diffie-hellman-group-exchange-sha1. So wie ich es verstehe, unterstützt dieser Algorithmus einen Bereich von Bitlängen, den Client und Server dann aushandeln müssen. Unter normalen Umständen einigen sich Client und Server auf eine Bitlänge und tauschen Schlüssel unter Verwendung einer DH-Primzahl aus der moduliDatei aus, z. B. /etc/ssh/moduli(Ich weiß, dass diese letzte Aussagesehr„Laiensprache“, aber das ist ungefähr die lange und die kurze Version).

In diesem Fall glaube ich zu sehen, dass die Bitlängenverhandlung fehlschlägt. In Zeile 49 sagt der Client (ich) „Ich unterstütze Bitlängen zwischen 1536 und 8192 und möchte 3072 Bit verwenden.“ Der Server antwortet jedoch und sagt „Ich unterstütze nur 1024 Bit.“ An diesem Punkt gibt der Client auf und sagt „Ich kann nicht mit Ihnen sprechen.“ Ist das eine vernünftige Beschreibung dessen, was hier passiert?

So wie ich es verstehe, liegt das Problem an dieser Stelle ausschließlich auf der Serverseite (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 dies richtig verstehe, bevor ich fortfahre. Input ist willkommen.

Antwort1

Wenn Sie neueres OpenSSH zur Verbindung mit veralteten Servern verwenden möchten:

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/6069erwähnt den folgenden Fix auf Mikrotik-Routerboards:

/ip ssh set strong-crypto=yes

(Ich vermerke dies hier, da diese Antwort auch bei Websuchen angezeigt wird, 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

Antwort2

Es scheint, Sie haben dies getroffenInsekt.

Ursache

Am OpenSSH-Paket wurde eine Änderung vorgenommen, die sich mit dem Diffie-Hellman Group Exchange befasst. Bisher konnten Schlüssel der Größe 1024 - 8192 ausgetauscht werden. Das Minimum wurde auf 1536 erhöht, um die Sicherheit zu erhöhen und die Sicherheitslücke „Logjam“ zu vermeiden. Bei Verwendung mit einigen SSH-Implementierungen von Drittanbietern, die nur 1024 unterstützen, treten jedoch Fehler auf. Idealerweise sollte die SSH-Konfiguration oder der Code von Drittanbietern aktualisiert werden, um größere Schlüsselgrößen zu verwenden.

...

Im Link finden Sie 3 verschiedene Lösungen. In Situationen, in denen Sie keine Administratorrechte haben oder der bürokratische Aufwand zu groß ist, um tiefere Änderungen vorzunehmen, schien mir die beste Option, den problematischen Algorithmus zu entfernen, während man auf die Verfügbarkeit von SHA-2 auf dem Server wartet. Sie können dies sogar benutzerbasiert in Ihrer Datei $HOME/.ssh/config durchführen.

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

verwandte Informationen