SSH: grupo DH_GEX fora do intervalo

18

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

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

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

Portanto, 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 bits que o cliente e o servidor precisam negociar. Em circunstâncias normais, o cliente e o servidor concordam com um pouco de comprimento e trocam as chaves usando um prime DH do moduliarquivo, por exemplo /etc/ssh/moduli(eu sei que essa última declaração é muito "falada por leigos", mas isso é aproximadamente o longo e o curto de isto).

Nesse caso, o que acho que estou vendo é que a negociação de tamanho de bit está falhando. Na linha 49, o cliente (eu) está dizendo "Eu ofereço comprimentos de bits entre 1536 e 8192 e quero usar 3072 bits". No entanto, o servidor responde e diz "Eu só suporte 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 está inteiramente no servidor no momento (assumindo que não negociamos um algoritmo mais fraco como diffie-hellman-group1-sha1). O servidor precisaria ser modificado para suportar comprimentos de bits maiores durante o processo de troca de chaves.

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

linux  ssh  linux-networking  sles 
— sbrown
fonte
1
Você está lendo certo. O que há na outra extremidade? Isso não parece com nenhum servidor ssh comum.
— Michael Hampton
Não faço ideia do que é o servidor. Estamos enfrentando o mesmo problema com dois fornecedores diferentes, ambos bancos. Nenhum servidor se identifica na sessão (o que não é surpreendente).
— Sbrown # 14/15
Você pensaria que os bancos estariam um pouco mais além da segurança, mas ...
— Michael Hampton
2
A busca por "GXSSSHD_Comments" exibe comentários em vários fóruns de clientes SFTP, que, por sua vez, parecem sugerir que seu servidor é o aplicativo GXS MFT - muito empreendedor.
— Castaglia 13/01

Respostas:

21

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

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

Adicione -v se 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

https://forum.ctwug.za.net/t/fyi-openssh-to-access-rbs-openssh-7/6069 menciona a seguinte correção nas Routerboards Mikrotik:

/ip ssh set strong-crypto=yes

(Observe isso aqui porque esta resposta também aparece nas pesquisas na Web ao procurar uma mensagem de erro semelhante.)

Se você deseja usá-lo no 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
— Dagelf
fonte
2
isso funciona para sftp também
— bao7uo
11

Parece que você atingiu esse bug .

Causa

Foi feita uma alteração no pacote openssh, referente ao Diffie-Hellman Group Exchange. Anteriormente, as chaves do tamanho 1024 - 8192 podiam ser trocadas. O mínimo foi aumentado para 1536 para aumentar a segurança e evitar a vulnerabilidade "logjam". No entanto, se usado com algumas implementações ssh de terceiros que suportam apenas 1024, ocorrerá uma falha. Idealmente, a configuração ou código ssh de terceiros deve ser atualizada para usar tamanhos de chave maiores.

...

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

KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
— xmar
fonte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.