SSH: groupe DH_GEX hors plage
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 [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`
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 conviennent d'une longueur de bits et échangent des clés en utilisant un DH prime à partir du fichier moduli, par exemple /etc/ssh/moduli (Je sais que cette dernière affirmation est très "le discours des profanes", mais c'est à peu près le long et le court).
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 veux 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é.
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
Il semble que vous ayez atteint 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 en mode utilisateur dans votre fichier $ HOME/.ssh/config.
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1