SSH funciona em massa, mas não em terminal

Question

Quando tento ssh em um terminal: ssh [email protected] recebo o seguinte erro: Connection closed by 69.163.227.82

Quando uso o putty, consigo me conectar ao servidor. Por que isso está acontecendo e como posso fazer isso funcionar em um terminal?

ssh -v nomedeusuá[email protected]

OpenSSH_6.0p1 (CentrifyDC build 5.1.0-472) (CentrifyDC build 5.1.0-472), OpenSSL 0.9.8w 23 Apr 2012
debug1: Reading configuration data /etc/centrifydc/ssh/ssh_config
debug1: /etc/centrifydc/ssh/ssh_config line 52: Applying options for *
debug1: Connecting to sub.domain.com [69.163.227.82] port 22.
debug1: Connection established.
debug1: identity file /home/ryannaddy/.ssh/id_rsa type -1
debug1: identity file /home/ryannaddy/.ssh/id_rsa-cert type -1
debug1: identity file /home/ryannaddy/.ssh/id_dsa type -1
debug1: identity file /home/ryannaddy/.ssh/id_dsa-cert type -1
debug1: identity file /home/ryannaddy/.ssh/id_ecdsa type -1
debug1: identity file /home/ryannaddy/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0
debug1: Miscellaneous failure
Cannot resolve network address for KDC in requested realm

debug1: Miscellaneous failure
Cannot resolve network address for KDC in requested realm

debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
Connection closed by 69.163.227.82

    

Answer 1

Solução encontrada para mim por meio do seguinte URL: link

Até faz um bom trabalho explicando o que está acontecendo.

Por fim, adicionei o seguinte ao arquivo / etc / ssh / ssh_config:

Host *
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
HostKeyAlgorithms ssh-rsa,ssh-dss
MACs hmac-md5,hmac-sha1,hmac-ripemd160

Nem as cifras, nem o HostKeyAlgorithms funcionavam sozinhos, mas os MACs me colocaram por cima para que isso funcionasse, mas não posso ter certeza, coloquei muitas horas para resolver isso. Espero que isso possa pelo menos ajudar alguém.

Edit: Isso (algumas vezes) corrige o problema, mas provavelmente não da maneira que você quer. - jcwenger

Essas configurações parecem (como um efeito colateral) alterar a maneira como o cliente ssh emite pacotes e fazem com que ele emita pacotes menores. Isso não está corrigindo o problema; Às vezes, isso faz com que o problema real (fragmentação de MTU interagindo com implementações estúpidas de regras de firewall) não seja acionado.

A solução correta é definir uma MTU que funcione de ponta a ponta.

Ter que configurar manualmente o MTU para um número menor para garantir que não ocorra fragmentação não é mais limpo (nós, como usuários, não deveríamos ter que tomar medidas para combater problemas causados por nossas equipes de rede) ... mas pelo menos está lidando diretamente com a causa real de uma maneira confiável e comprovada, em vez de estragar as configurações de criptografia do SSH de um modo que, como um efeito colateral, quando as estrelas se alinham, faz com que ele não aumente pacotes.

Além disso, o SSH não é a única coisa que faz grandes pacotes. Definir o MTU impede que a mesma coisa aconteça com outros protocolos também.

    

Answer 2

Isso funcionou para mim ...

ifconfig eth0 mtu 576

link

    

Answer 3

Isso corrigiu o problema do MTU sem ter que codificar algum valor, ele irá consertá-lo para o ssh e qualquer outro protocolo afetado por isso. Como root, execute o seguinte:

echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing

Você pode ler mais sobre o problema e a solução aqui e aqui .

    

Answer 4

Alguns procuraram e encontraram a seguinte sugestão aqui :

Tente garantir que a seguinte linha em seu / etc / ssh / ssh_config (NÃO sshd_config) NÃO esteja comentada:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc

Você também pode tentar reverter esse arquivo para o padrão e tentar novamente, ou seja, desinstalar e reinstalar openssh-client IIRC o nome do pacote.

    

Answer 5

Altere a MTU da interface de rede para resolvê-lo. Este é um bug para o Ubuntu 14.04.

Isso funcionou para mim:

sudo ip li set mtu 1200 dev wlan0

Ou:

sudo ifconfig wlan0 mtu 1200

ssh falha ao conectar-se ao host VPN - trava em 'esperar SSH2_MSG_KEX_ECDH_REPLY'

    

Answer 6

Comecei a ter esse problema hoje, no Windows (ssh distribuído com o Git) e no Ubuntu.

Parece ser um bug no OpenSSH, há um problema no LauchPad .

Funcionou para mim no Windows forçando a cifra 3des-cbc e a chave no Ubuntu.

    

Answer 7

Consegui resolver esse problema forçando o uso do IPv4 com

ssh -4 [email protected]

Como estou em um Mac, não sei quais são as configurações de MTU aqui ou como alterá-las, mas achei que outras podem se beneficiar disso.

    

Answer 8

Um pouco de necro aqui, mas eu encontrei isso no OpenSSH_7.8p1, no Linux. A introdução da marcação DSCP nos lançamentos recentes do OpenSSH parece estar diminuindo no VMware NAT (a rede em ponte foi mencionada como boa nos links abaixo).

Você pode contornar isso por enquanto adicionando / definindo o seguinte para / etc / ssh / ssh_config :

IPQoS lowdelay throughput

Fatores adicionais seriam que o PuTTY (ou outros clientes SSH distintos) podem não estar encontrando o problema do mesmo host, e sua MTU até o momento deve ser verificada. ou seja:

ping -M do -s 1472 your-ssh-server

Essas postagens foram muito úteis e me levaram para onde eu precisava estar:

link link

    

Answer 9

ssh -c aes256-ctr funciona bem;