ssh incapaz de negociar - não foi encontrado nenhum método de troca de chaves correspondente

Question

Estou tentando fazer login no meu roteador DSL, porque estou tendo problemas com o correio da linha de comando. Eu estou esperando poder reconfigurar o roteador.

Quando dou o comando ssh , é isso que acontece:

$ ssh [email protected]

Unable to negotiate with 10.255.252.1 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

então olhei para esse post do stackexchange , e modifiquei meu comando para isso, mas eu tenho um problema diferente, dessa vez com as cifras.

$ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 [email protected]

Unable to negotiate with 10.255.252.1 port 22: no matching cipher found. Their offer: 3des-cbc

Então existe um comando para oferecer 3des-cbc encryption? Não tenho certeza sobre o 3des, como se eu quiser adicioná-lo permanentemente ao meu sistema.

Existe um comando para permitir a 3des-cbc cipher?

Qual é o problema aqui? Não está pedindo senha.

    

Answer 1

Esse erro específico ocorre enquanto o canal criptografado está sendo configurado. Se o seu sistema e o sistema remoto não compartilharem pelo menos uma cifra, não haverá codificação para concordar e nenhum canal criptografado será possível. Normalmente, os servidores SSH oferecem um pequeno número de diferentes cifras para atender diferentes clientes; Não sei por que o seu servidor seria configurado para permitir apenas o 3DES-CBC.

Agora, o 3DES-CBC não é terrível. É lento e fornece menos segurança do que alguns outros algoritmos, mas não é imediatamente quebrável, desde que as chaves sejam selecionado corretamente. O próprio CBC tem alguns problemas quando o texto cifrado pode ser modificado em trânsito, mas eu suspeito strongmente que o resultado a corrupção seria rejeitada pelo HMAC da SSH, reduzindo o impacto. Bottom line, há escolhas piores do que 3DES-CBC, e há melhores. No entanto, sempre avance com cuidado ao substituir os padrões relacionados à segurança, incluindo as opções de algoritmo de troca de chaves e criptografia. Esses padrões são os padrões de um motivo; algumas pessoas muito inteligentes gastaram algum poder do cérebro considerando as opções e determinaram que o que foi escolhido como padrão fornece o melhor compromisso geral de segurança versus desempenho.

Como você descobriu, você pode usar -c ... (ou -oCiphers=... ) para especificar qual codificação oferecer do lado do cliente. Neste caso, adicionar -c 3des-cbc permite apenas o 3DES-CBC do cliente. Como isso corresponde a uma cifra oferecida pelo servidor, um canal criptografado pode ser estabelecido e a conexão prossegue para a fase de autenticação.

Você também pode adicionar isso ao seu ~/.ssh/config pessoal. Para evitar uma alteração global para resolver um problema local, você pode colocá-lo em uma sub-rotina Host . Por exemplo, se sua configuração de SSH diz atualmente (exemplo fictício):

Port 9922

especificando uma porta padrão global de 9922 em vez do padrão 22, é possível incluir uma sub-rotina de host para o host que precisa de configuração especial e uma sub-rotina de host global para o caso padrão. Isso se tornaria algo como ...

Host 10.255.252.1
    Ciphers 3des-cbc
    KexAlgorithms +diffie-hellman-group1-sha1
Host *
    Port 9922

O recuo é opcional, mas acho que aumenta muito a legibilidade. Linhas em branco e linhas começando com # são ignoradas.

Se você sempre (ou principalmente) fizer login como o mesmo usuário nesse sistema, também poderá especificar esse nome de usuário:

Host 10.255.252.1
    Ciphers 3des-cbc
    KexAlgorithms +diffie-hellman-group1-sha1
    User enduser
Host *
    Port 9922

Você não precisa adicionar uma sub-rotina Host * se não houvesse nada em seu ~ / .ssh / config para começar, como nesse caso apenas os padrões compilados ou de todo o sistema (tipicamente de / etc / ssh / ssh_config) seria usado.

Neste ponto, a linha de comando ssh para se conectar a este host reduz a simples

$ ssh 10.255.252.1

e todos os outros usuários no seu sistema, e conexões com todos os outros hosts do seu sistema, não são afetados pelas alterações.

    

Answer 2

Ok, li a manpage e descobri.

Eu não queria modificar meu arquivo de configuração e, por isso, procurei o termo "cipher" na man page que me mostrou a opção -c ; Isso me permite especificar o tipo de criptografia. o comando final foi então:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c 3des-cbc [email protected]

    

Answer 3

Recentemente encontrei esse problema usando o PuTTY para conectar-me a uma versão mais recente do Ubuntu. Parece que versões anteriores do PuTTY não tinham cifras atualizadas. Então baixar a última versão do PuTTY resolveu o problema. Isso poderia ser outra solução.

    

Answer 4

Outra resposta para o MacOSX e o CLI comamnds (SFTP, por exemplo): consulte este artigo @ link (OpenSSL Legacy Opções). Eu estava recebendo um erro consistente de "não poderia negociar", que foi resolvido por informações neste artigo, especificamente a configuração de um parâmetro de configuração no arquivo "~ / .ssh / config".

Demorei algumas horas para encontrar este artigo em particular e referência, por isso espero que ajude alguém nesta lista.

BTW, recebi esse erro quando meu servidor SFTP de destino (não sob minha administração) finalmente desativou o TLS 1.0 (opção de criptografia SSL) e requer o TLS 1.1 ou 1.2.