SSH: grupo DH_GEX fuera de rango

18

Recientemente aplicamos un parche suministrado por el proveedor para OpenSSH. Este parche deshabilitó algunos protocolos de intercambio de claves en respuesta al reciente ataque de Logjam. Después de aplicar este parche, tenemos algunos proveedores con los que no hemos podido intercambiar archivos a través de sftp porque la negociación de conexión está fallando (probablemente debido a los algoritmos de intercambio de claves obsoletos).

Solo me gustaría verificar un par de cosas que estamos viendo antes de hablar con nuestros proveedores. Aquí hay una sesión de muestra SSH con uno de los proveedores problemáticos (se agregaron números de línea):

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

Entonces, durante la negociación de intercambio de claves, el cliente y el servidor intercambian sus listas de algoritmos compatibles (líneas 21 y 33). Acuerdan usar la primera coincidencia encontrada en las dos listas, en este caso diffie-hellman-group-exchange-sha1. Según tengo entendido, este algoritmo admite un rango de longitudes de bits que el cliente y el servidor deben negociar. En circunstancias normales, el cliente y el servidor acuerdan un poco de longitud e intercambian claves haciendo uso de un DH prime del moduliarchivo, por ejemplo /etc/ssh/moduli(sé que esta última declaración es muy "la palabra de los laicos", pero eso es más o menos largo y corto) eso).

En este caso, lo que creo que estoy viendo es que la negociación de longitud de bits está fallando. En la línea 49, el cliente (yo) dice "Apoyo longitudes de bits entre 1536 y 8192 y quiero usar 3072 bits". Sin embargo, el servidor responde y dice "Solo soporto 1024 bits". En ese momento el cliente se da por vencido y dice "No puedo hablar contigo". ¿Es esta una descripción razonable de lo que está sucediendo aquí?

Según tengo entendido, el problema está completamente en el servidor en este punto (suponiendo que no negociemos un algoritmo más débil como diffie-hellman-group1-sha1). El servidor tendría que modificarse para admitir las longitudes de bits más grandes durante el proceso de intercambio de claves.

Me gustaría asegurarme de entender esto correctamente antes de continuar. Se agradece la entrada.

linux  ssh  linux-networking  sles 
— sbrown
fuente
1
Lo estás leyendo bien. ¿Qué demonios hay en el otro extremo? Eso no se parece a ningún servidor ssh común.
— Michael Hampton
No tengo idea de qué es el servidor. Estamos experimentando el mismo problema con dos proveedores diferentes, los cuales son bancos. Ninguno de los servidores se identifica en la sesión (lo cual no es sorprendente).
— sbrown
Se podría pensar que los bancos estarían un poco más por encima de la seguridad, pero por desgracia ...
— Michael Hampton
2
Al buscar "GXSSSHD_Comments" aparecen comentarios en varios foros de clientes SFTP, que a su vez parecen sugerir que su servidor es la aplicación GXS MFT , muy emprendedor.
— Castaglia

Respuestas:

21

Si desea utilizar OpenSSH más nuevos para conectarse a servidores obsoletos:

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

Agregue -v si desea ver lo que está sucediendo y -o HostKeyAlgorithms = ssh-dss si aún no funciona:

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

También puede, por supuesto, editar / etc / ssh / ssh_config o ~ / .ssh / ssh_config, y agregar:

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 menciona la siguiente solución en las placas de enrutamiento Mikrotik:

/ip ssh set strong-crypto=yes

(Observando esto aquí porque esta respuesta también aparece en las búsquedas web cuando se busca un mensaje de error similar).

Si desea usarlo sobre Git sin editar su ssh_config o actualizar el servidor SSH:

GIT_SSH="ssh -oHostKeyAlgorithms=+ssh-dss -oKexAlgorithms=diffie-hellman-group14-sha1" git clone ssh://user@host/path-to-repository
— Dagelf
fuente
2
esto funciona para SFTP también
— bao7uo
11

Parece que has golpeado este error .

Porque

Se realizó un cambio en el paquete openssh, que trata con Diffie-Hellman Group Exchange. Anteriormente, se podían intercambiar claves del tamaño 1024 - 8192. El mínimo se elevó a 1536 para mayor seguridad y para evitar la vulnerabilidad "logjam". Sin embargo, si se usa con algunas implementaciones ssh de terceros que solo admiten 1024, se producirá un error. Idealmente, la configuración o código ssh de terceros debe actualizarse para usar tamaños de clave más grandes.

...

Puede encontrar 3 resoluciones diferentes en el enlace. En situaciones en las que no tiene poder de administración o hay demasiada burocracia para obtener cambios más profundos, deshacerme del algoritmo problemático mientras esperaba la disponibilidad de SHA-2 en el servidor me pareció la mejor opción. Incluso puede realizarlo de manera basada en el usuario en su archivo $ HOME / .ssh / config.

KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
— xmar
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.