SSH funciona em massa, mas não terminal

Quando tento ssh isso em um terminal: ssh username@sub.domain.comEu recebo o seguinte erro:
Connection closed by 69.163.227.82

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

ssh -v nomedeusuário@sub.domínio.com

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

Solução encontrada para mim através do seguinte URL: http://www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connection-reset-by-peer/

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

Por fim, adicionei o seguinte ao / 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 o Ciphers, nem o HostKeyAlgorithms funcionaram por conta própria, com certeza os MACs me colocaram no topo para fazer com que isso funcionasse, mas não tenho certeza, dedique muitas horas para resolver isso. Espero que isso possa pelo menos ajudar outra pessoa.

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

Essas configurações parecem (como efeito colateral) alterar a maneira como o cliente ssh emite pacotes e fazem com que ele emita pacotes menores. Isso não está resolvendo o problema; às vezes, faz com que o problema real (fragmentação do 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 definir 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 devemos tomar medidas manualmente 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 comprovável, em vez de estragar as configurações de cifra do SSH de uma maneira que, como efeito colateral, quando as estrelas se alinham, faz com que ela não produza pacotes grandes.

Além disso, o SSH não é a única coisa que produz grandes pacotes. A configuração do MTU evita que a mesma coisa aconteça com outros protocolos.

Isso funcionou para mim ...

ifconfig eth0 mtu 576

http://fred-web.blogspot.com.au/2012/10/ssh-hang-on-expecting.html

Isso corrigiu o problema do MTU sem ter que codificar algum valor, ele corrigirá o ssh e qualquer outro protocolo efetuado 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 .

Fiz algumas pesquisas e encontrei a seguinte sugestão aqui :

Tente verificar se a seguinte linha no seu / etc / ssh / ssh_config (NÃO sshd_config) NÃO está 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 o openssh-clientIIRC no nome do pacote.

Mude a interface de rede MTU para resolvê-lo. Este é um erro do ubuntu 14.04.

Isso funcionou para mim:

sudo ip li set mtu 1200 dev wlan0

Ou:

sudo ifconfig wlan0 mtu 1200

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

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

ssh -4 username@host.xyz

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 pessoas poderiam se beneficiar disso.

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

Parece ser um bug no OpenSSH, existe um problema no LauchPad .

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

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

Você pode contornar isso por enquanto adicionando / configurando o seguinte em / etc / ssh / ssh_config :

IPQoS lowdelay throughput

Fatores adicionais seriam que o PuTTY (ou outros clientes SSH distintos) pode não estar encontrando o problema no mesmo host, e sua MTU até agora faz check-out. ou seja:

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

Essas postagens foram de especial utilidade e me levaram aonde eu precisava estar:

https://groups.google.com/forum/#!topic/opensshunixdev/5FK67SCpPg8 https://groups.google.com/forum/#!topic/opensshunixdev/uNd48nGOe7A

ssh -c aes256-ctr funciona bem;