SSH funciona en masilla pero no en terminal

Cuando intento ssh esto en una terminal: ssh [email protected]me sale el siguiente error:
Connection closed by 69.163.227.82

Cuando uso masilla, puedo conectarme al servidor. ¿Por qué sucede esto y cómo puedo hacer que funcione en una terminal?

ssh -v [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

Solución encontrada para mí a través de la siguiente URL: http://www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connection-reset-by-peer/

Incluso hace un muy buen trabajo al explicar lo que está sucediendo.

Finalmente, agregué lo siguiente a / 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

Ni Ciphers ni HostKeyAlgorithms trabajaron solos, estoy bastante seguro de que los MAC me pusieron en la cima para que esto funcione, pero no puedo estar seguro, dedicaron muchas horas a resolver esto. Espero que esto al menos pueda ayudar a alguien más.

Editar: esto (a veces) soluciona el problema, pero probablemente no de la manera que desea. --jcwenger

Parece que esta configuración (como efecto secundario) cambia la forma en que el cliente ssh emite paquetes y ocasiona que emita paquetes más pequeños. Esto no está solucionando el problema; simplemente, a veces, hace que el problema real (la fragmentación de MTU que interactúa con estúpidas implementaciones de reglas de firewall) no se active.

La solución correcta es establecer una MTU que funcione de extremo a extremo.

Tener que configurar manualmente MTU en un número menor para garantizar que no ocurra fragmentación no es más limpio (nosotros, como usuarios, no deberíamos tener que tomar medidas manualmente para contrarrestar los problemas causados ​​por nuestros equipos de red) ... pero al menos se trata directamente con la causa real de una manera confiable y comprobable, en lugar de arruinar la configuración de cifrado de SSH de una manera que, como efecto secundario, cuando las estrellas se alinean, hace que no se formen grandes paquetes.

Además, SSH no es lo único que hace grandes paquetes. La configuración de MTU evita que ocurra lo mismo con otros protocolos también.

Esto funcionó para mí ...

ifconfig eth0 mtu 576

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

Esto solucionó el problema de MTU sin tener que codificar algún valor, lo solucionará para ssh y cualquier otro protocolo efectuado por esto. Como root ejecuta lo siguiente:

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

Puede leer más sobre el problema y la solución aquí y aquí .

Busqué y encontré la siguiente sugerencia aquí :

Intente asegurarse de que la siguiente línea en su / etc / ssh / ssh_config (NOT sshd_config) NO esté comentada:

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

También puede intentar revertir ese archivo al valor predeterminado e intentarlo nuevamente, es decir, desinstalar y volver a instalar openssh-clientIIRC el nombre del paquete.

Cambie la interfaz de red MTU para resolverlo. Este es un error para ubuntu 14.04.

Esto funcionó para mí:

sudo ip li set mtu 1200 dev wlan0

O:

sudo ifconfig wlan0 mtu 1200

ssh no puede conectarse al host VPN: se bloquea en 'esperando SSH2_MSG_KEX_ECDH_REPLY'

Pude resolver este problema obligando a usar IPv4 con

ssh -4 [email protected]

Como estoy en una Mac, no sé cuáles son las configuraciones de MTU aquí ni cómo cambiarlas, pero pensé que otros podrían beneficiarse de esto.

Empecé a tener este problema hoy, en Windows (ssh distribuido con Git) y Ubuntu.

Parece ser un error en OpenSSH, hay un problema en LauchPad .

Funcionó para mí en Windows forzando el cifrado 3des-cbc y la clave en Ubuntu.

Un poco necro aquí, pero encontré esto en OpenSSH_7.8p1, en Linux. La introducción de la marca DSCP en versiones recientes de OpenSSH parece estar tropezando en VMware NAT (se mencionó que las redes en puente están bien en los enlaces a continuación).

Puede solucionar esto por ahora agregando / configurando lo siguiente en / etc / ssh / ssh_config :

IPQoS lowdelay throughput

Factores adicionales serían que PuTTY (u otros clientes SSH distintos) pueden no estar encontrando el problema desde el mismo host, y su MTU hasta ahora se verifica. es decir:

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

Estas publicaciones fueron de particular ayuda y me llevaron a donde necesitaba estar:

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

ssh -c aes256-ctr funciona bien;