SSH: groupe DH_GEX hors limites

Nous avons récemment appliqué un correctif fourni par le fournisseur pour OpenSSH. Ce correctif a désactivé quelques protocoles d'échange de clés en réponse à la récente attaque Logjam. Après avoir appliqué ce correctif, nous avons quelques fournisseurs avec lesquels nous n'avons pas pu échanger de fichiers via sftp car la négociation de connexion échoue (probablement en raison des algorithmes d'échange de clés obsolètes).

Je voudrais juste vérifier deux ou trois choses que nous voyons avant de parler à nos fournisseurs. Voici un exemple de session SSH avec l'un des fournisseurs problématiques (numéros de ligne ajoutés):

# 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`

Ainsi, lors de la négociation d'échange de clés, le client et le serveur échangent leurs listes d'algorithmes pris en charge (lignes 21 et 33). Ils acceptent d'utiliser la première correspondance trouvée dans les deux listes, dans ce cas diffie-hellman-group-exchange-sha1. Si je comprends bien, cet algorithme prend en charge une gamme de longueurs de bits que le client et le serveur doivent ensuite négocier. Dans des circonstances normales, le client et le serveur d' accord sur une longueur de bits et les clés d'échange faisant usage d'un premier DH du modulifichier, par exemple /etc/ssh/moduli(je sais que cette dernière affirmation est très « parler pour les laïcs », mais est à peu près le long et le court il).

Dans ce cas, ce que je pense voir, c'est que la négociation sur la longueur des bits échoue. À la ligne 49, le client (moi) dit "Je prends en charge des longueurs de bits comprises entre 1536 et 8192 et je souhaite utiliser 3072 bits". Cependant, le serveur répond en retour et dit "je ne supporte que 1024 bits". À ce moment-là, le client abandonne et dit "Je ne peux pas te parler." Est-ce une description raisonnable de ce qui se passe ici?

Si je comprends bien, le problème est entièrement sur le serveur à ce stade (en supposant que nous ne négocions pas un algorithme plus faible comme diffie-hellman-group1-sha1). Le serveur devrait être modifié pour prendre en charge les plus grandes longueurs de bits pendant le processus d'échange de clés.

Je voudrais m'assurer de bien comprendre cela avant de continuer. L'apport est apprécié.

— brun
source

Vous le lisez bien. Que diable est à l'autre bout? Cela ne ressemble à aucun serveur ssh commun.

— Michael Hampton

Aucune idée de ce qu'est le serveur. Nous rencontrons le même problème avec deux fournisseurs différents, tous deux des banques. Aucun des serveurs ne s'identifie dans la session (ce qui n'est pas surprenant).

— sbrown

On pourrait penser que les banques seraient un peu plus en plus de la sécurité, mais hélas ...

— Michael Hampton

La recherche de "GXSSSHD_Comments" fait apparaître des commentaires dans divers forums clients SFTP, qui à leur tour semblent suggérer que votre serveur est l' application GXS MFT - très entreprenant.

— Castaglia

Si vous souhaitez utiliser OpenSSH plus récent pour vous connecter à des serveurs obsolètes:

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

Ajoutez -v si vous voulez voir ce qui se passe et -o HostKeyAlgorithms = ssh-dss si cela ne fonctionne toujours pas:

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

Vous pouvez également, bien sûr, éditer / etc / ssh / ssh_config ou ~ / .ssh / ssh_config, et ajouter:

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 mentionne le correctif suivant sur les cartes de routeur Mikrotik:

/ip ssh set strong-crypto=yes

(Notez cela ici, car cette réponse apparaît également dans les recherches sur le Web lorsque vous recherchez un message d'erreur similaire.)

Si vous souhaitez l'utiliser sur Git sans modifier votre ssh_config ou mettre à jour le serveur SSH:

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

— Dagelf
source

cela fonctionne aussi pour sftp

— bao7uo

Il semble que vous ayez rencontré ce bug .

Cause

Une modification a été apportée au package openssh, traitant de Diffie-Hellman Group Exchange. Auparavant, les clés de taille 1024 à 8192 pouvaient être échangées. Le minimum a été relevé à 1536 pour plus de sécurité et pour éviter la vulnérabilité "logjam". Cependant, s'il est utilisé avec certaines implémentations ssh tierces qui ne prennent en charge que 1024, un échec se produira. Idéalement, la configuration ou le code ssh tiers devrait être mis à jour pour utiliser des tailles de clé plus grandes.

...

Vous pouvez trouver 3 résolutions différentes dans le lien. Dans les situations où vous n'avez pas de pouvoir d'administrateur ou où il y a trop de bureaucratie pour obtenir des changements plus profonds, se débarrasser de l'algorithme problématique en attendant une disponibilité de SHA-2 sur le serveur me semblait la meilleure option. Vous pouvez même l'exécuter de manière utilisateur dans votre fichier $ HOME / .ssh / config.

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

— xmar
source