Recentemente, aplicamos um patch fornecido pelo fornecedor para 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 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 falar com nossos fornecedores. Aqui está um exemplo de sessão SSH 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 uma variedade de comprimentos de bits que o cliente e o servidor precisam negociar. Em circunstâncias normais, o cliente e o servidor concordam com o tamanho do bit e trocam chaves usando um DH prime do moduliarquivo, por exemplo /etc/ssh/moduli(eu sei que esta última afirmação émuito"fala de leigo", mas isso é aproximadamente o resumo).
Neste caso, o que penso estar a ver é que a negociação de comprimento de bits está a falhar. Na linha 49, o cliente (eu) está dizendo "Suporto comprimentos de bits entre 1536 e 8192 e quero usar 3072 bits". No entanto, o servidor responde e diz "Só suporto 1024 bits". Nesse ponto 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 neste ponto (assumindo que não negociamos um algoritmo mais fraco como o diffie-hellman-group1-sha1). O servidor teria que ser modificado para suportar comprimentos de bits maiores durante o processo de troca de chaves.
Gostaria de ter certeza de que entendi isso corretamente antes de prosseguir. A contribuição é apreciada.
Responder1
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 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/6069menciona a seguinte correção em Mikrotik Routerboards:
/ip ssh set strong-crypto=yes
(Observando isso aqui porque essa resposta também aparece em pesquisas na web ao procurar uma mensagem de erro semelhante.)
Se você quiser 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
Responder2
Parece que você acertou issoerro.
Causa
Foi feita uma alteração no pacote openssh, tratando do Diffie-Hellman Group Exchange. Anteriormente, chaves de tamanho 1024 - 8192 podiam ser trocadas. O mínimo foi aumentado para 1536 para maior segurança e para evitar a vulnerabilidade de “logjam”. No entanto, se usado com algumas implementações ssh de terceiros que suportam apenas 1024, ocorrerá falha. Idealmente, a configuração ou código SSH de terceiros deve ser atualizado para usar tamanhos de chave maiores.
...
Você pode encontrar 3 resoluções diferentes no link. Em situações onde você não tem poder de administração ou há muita burocracia para conseguir mudanças mais profundas, livrar-se do algoritmo problemático enquanto espera pela disponibilidade do SHA-2 no servidor me pareceu a melhor opção. Você pode até mesmo executá-lo com base no usuário em seu arquivo $HOME/.ssh/config.
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1