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 [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`
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.
fuente
Respuestas:
Si desea utilizar OpenSSH más nuevos para conectarse a servidores obsoletos:
Agregue -v si desea ver lo que está sucediendo y -o HostKeyAlgorithms = ssh-dss si aún no funciona:
También puede, por supuesto, editar / etc / ssh / ssh_config o ~ / .ssh / ssh_config, y agregar:
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:
(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:
fuente
Parece que has golpeado este error .
...
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.
fuente