Por que a chave pública faz login com o ssh, mas não com o x2go?

Question

Estou conectando de um sistema Mac OS X para um servidor Linux. Eu configurei o acesso à chave pública RSA, para que eu possa digitar

ssh [hostname]

e ele se conectará sem uma senha.

Ao tentar se conectar ao cliente de área de trabalho remota x2go, recebo um erro:

kex error : did not find one of algos diffie-hellman-group1-sha1 in list [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1 for kex algos

Meu sistema Mac OS X é bem antigo, rodando o Snow Leopard 10.6.8. O sistema Linux está bastante atualizado. A versão relatada por ssh -v é

OpenSSH_5.2p1, OpenSSL 0.9.8y 5 Feb 2013

Ouvi dizer que esse erro kex pode indicar uma incompatibilidade de algoritmos de criptografia no cliente e no servidor. Mas por que o ssh sucede onde o x2go falha? Posso obter o x2go para fazer o que o ssh fizer para fazer o login com sucesso? Parte do problema é que o x2go não reporta a sequência de eventos (ao contrário do ssh -v), então não sei exatamente o que é tentado fazer. Se houver uma maneira de mostrar um log detalhado que seria útil.

    

Answer 1

Sim, é uma incompatibilidade de algoritmo de troca de chaves. (Não tem nada a ver com "login de chave pública" do seu lado. Eles são fases completamente separadas.)

O problema vem de:

• O X2go agrupa uma biblioteca cliente SSH de baixa qualidade que nem sequer implementa as partes necessárias da especificação SSH v2 (encontrei um Relatório de erros X2go em relação a essa situação) e

• seguindo cegamente as instruções de algum blog (provavelmente "Secure Secure Shell"?) para limitar o servidor SSH a um subconjunto muito pequeno de algoritmos de troca de chaves, nenhum dos quais é suportado pela biblioteca cliente X2go. / p>

Normalmente, usar uma biblioteca como a libssh para conexões SSH é aceitável - trabalhar com funções de biblioteca é um pouco mais conveniente do que manipular os comandos /usr/bin/ssh em segundo plano. No entanto, o X2go no seu sistema usa uma versão muito antiga do libssh - ele implementa apenas diffie-hellman-group1-sha1 , mas não diffie-hellman-group14-sha1 , embora RFC 4253 requer ambos .

(A diferença é que "group1" (Oakley Group 2 [sic]) usa parâmetros DH de 1024 bits, que não protegem mais o suficiente O grupo 14, por sua vez, usa parâmetros de 2048 bits.

Você disse que seu sistema Linux está "razoavelmente atualizado". Quando se trata de software criptográfico, isso não é nem perto - o mais recente OpenSSH é o 7.1 (sua versão tem 6 anos), o último OpenSSL é 1.0.2d (sua versão tem 2 anos), e o último libssh é 0.7.2 (sua versão é… antiga).

• Portanto, a melhor solução seria instalar a versão mais recente do libssh , que suporta uma ampla variedade de algoritmos de troca de chaves (como o mesmo [email protected] ). No entanto, provavelmente será necessário pelo menos o OpenSSL 1.0.x para o suporte ao algoritmo de curva elíptica. Então, se você está preso a uma distribuição Linux mais antiga, isso pode ser problemático ...

• O outro método é a lista de permissões diffie-hellman-group1-sha1 na lista KexAlgorithms do seu servidor, junto com as listadas atualmente. Isso resultará em conexões X2go comparativamente fracas - strongs o suficiente contra seus vizinhos, mas possivelmente fracas contra as agências de três letras. No entanto, você ainda está usando uma versão do OpenSSH a partir de 2009, então provavelmente isso não importa para você de qualquer maneira.