SSH: grupo DH_GEX fora do intervalo

Question

Recentemente, aplicamos um patch fornecido pelo fornecedor para o OpenSSH. Este patch desativou alguns protocolos de troca de chaves em resposta ao recente ataque Logjam. Depois de aplicar esse patch, temos alguns fornecedores com os quais não pudemos trocar arquivos via sftp porque a negociação da conexão está falhando (provavelmente devido aos algoritmos de troca de chaves reprovados).

Gostaria apenas de verificar algumas coisas que estamos vendo antes de conversar com nossos fornecedores. Aqui está uma sessão SSH de amostra com um dos fornecedores problemáticos (números de linha adicionados):

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

Assim, durante a negociação de troca de chaves, o cliente e o servidor trocam suas listas de algoritmos suportados (linhas 21 e 33). Eles concordam em usar a primeira correspondência encontrada nas duas listas, neste caso diffie-hellman-group-exchange-sha1 . Pelo que entendi, esse algoritmo suporta um intervalo de comprimentos de bits que o cliente e o servidor precisam negociar. Em circunstâncias normais, o cliente e o servidor concordam com um comprimento de bit e troca de chaves que fazem uso de um DH prime do arquivo moduli , por exemplo. /etc/ssh/moduli (Eu sei que esta última afirmação é muito "fala dos leigos", mas isso é aproximadamente o longo e curto).

Nesse caso, o que acho que estou vendo é que a negociação de comprimento de bit está falhando. Na linha 49, o cliente (eu) está dizendo "Eu aceito comprimentos de bits entre 1536 e 8192 e quero usar 3072 bits". No entanto, o servidor responde de volta e diz "Eu só suporto 1024 bits". Nesse momento, o cliente desiste e diz "não posso falar com você". Esta é uma descrição razoável do que está acontecendo aqui?

Pelo que entendi, o problema é inteiramente no servidor neste ponto (assumindo que não negociamos um algoritmo mais fraco como diffie-hellman-group1-sha1 ). O servidor teria que ser modificado para suportar os maiores comprimentos de bits durante o processo de troca de chaves.

Gostaria de ter certeza de que estou entendendo isso corretamente antes de prosseguir. A entrada é apreciada.

    

Answer 1

Se você quiser usar o OpenSSH mais recente para se conectar a servidores obsoletos:

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

Adicione -v se você quiser ver o que está acontecendo, e -o HostKeyAlgorithms = ssh-dss se ainda não funcionar:

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

Você também pode, é claro, editar / etc / ssh / ssh_config ou ~ / .ssh / ssh_config e adicionar:

Host my.host.com *.myinsecure.net 192.168.1.* 192.168.2.*
    HostKeyAlgorithms ssh-dss
    KexAlgorithms diffie-hellman-group1-sha1    

link menciona a seguinte correção no Mikrotik Routerboards:

/ip ssh set strong-crypto=yes

(Observando isso aqui, porque essa resposta também aparece em pesquisas da Web ao procurar por uma mensagem de erro semelhante).

Se você quiser usá-lo sobre o Git sem editar seu ssh_config ou atualizar o servidor SSH:

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

    

Answer 2

Parece que você acertou este bug .

Cause

A change was made to the openssh package, dealing with Diffie-Hellman Group Exchange. Previously, keys of size 1024 - 8192 could be exchanged. The minimum was raised to 1536 for added security and to avoid the "logjam" vulnerability. However, if used with some 3rd party ssh implementations which only support 1024, failure will occur. Ideally, the 3rd party ssh configuration or code should be updated to use larger key sizes.

...

Você pode encontrar 3 resoluções diferentes no link. Em situações em que você não tem poder administrativo ou há muita burocracia para obter mudanças mais profundas, livrar-se do algoritmo problemático enquanto aguarda uma disponibilidade do SHA-2 no servidor pareceu-me a melhor opção. Você pode até mesmo executá-lo de forma baseada no usuário em seu arquivo $ HOME / .ssh / config.

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