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 [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`
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.
fonte
Respostas:
Se você deseja usar o OpenSSH mais recente para conectar-se a servidores obsoletos:
Adicione -v se quiser ver o que está acontecendo e -o HostKeyAlgorithms = ssh-dss se ainda não funcionar:
Você também pode, é claro, editar / etc / ssh / ssh_config ou ~ / .ssh / ssh_config e adicionar:
https://forum.ctwug.za.net/t/fyi-openssh-to-access-rbs-openssh-7/6069 menciona a seguinte correção nas Routerboards Mikrotik:
(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:
fonte
Parece que você atingiu esse bug .
...
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.
fonte