SSH可在腻子中使用，但不能在终端上使用

当我尝试在终端中使用ssh时：ssh username@sub.domain.com我收到以下错误：
Connection closed by 69.163.227.82

使用腻子时，我可以连接到服务器。为什么会发生这种情况，如何在终端中使用它呢？

ssh -v username@sub.domain.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

通过以下URL为我找到了解决方案：http : //www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connection-reset-by-peer/

它甚至可以很好地解释正在发生的事情。

最终，我在/ 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

无论是Ciphers还是HostKeyAlgorithms都不能单独工作，可以肯定的是MAC将我放在首位才能使它正常工作，但是我不确定，要花很多时间才能解决这个问题。我希望这至少可以帮助其他人。

编辑：这（有时）解决了问题，但可能不是您想要的方式。 --jcwenger

这些设置似乎（作为副作用）改变了ssh客户端发出数据包的方式，并恰巧导致其发出较小的数据包。这不能解决问题。有时，这样做只是为了避免触发真正的问题（与愚蠢的防火墙规则实现交互的MTU碎片）。

正确的解决方案是设置一个端到端工作的MTU。

无需手动设置MTU一个较小的数字，以确保没有出现碎片是没有任何清洁剂（我们作为用户不应该手动采取措施引起我们的网络团队计数器问题）...但它至少不直接处理以一种可靠且可证明的方式证明实际原因，而不是以某种方式搞乱SSH的密码设置，这种副作用是，当星星对齐时，碰巧会导致它不会产生大数据包。

此外，SSH并不是唯一产生大数据包的东西。设置MTU也可以防止其他协议发生同样的事情。

这对我有用...

ifconfig eth0 mtu 576

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

这样就解决了MTU问题，而无需硬编码一些值，它将针对ssh和由此影响的任何其他协议进行修复。以root用户身份运行以下命令：

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

您可以在此处和此处阅读有关该问题和解决方案的更多信息。

经过一番寻找，在这里发现了以下建议：

尝试确保/ etc / ssh / ssh_config中的以下行（不sshd_config）未被注释掉：

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

您也可以尝试将该文件还原为默认文件，然后重试，即卸载并重新安装openssh-clientIIRC程序包的名称。

更改网络接口MTU即可解决。这是Ubuntu 14.04的错误。

这为我工作：

sudo ip li set mtu 1200 dev wlan0

要么：

sudo ifconfig wlan0 mtu 1200

ssh无法连接到VPN主机-挂在“期望SSH2_MSG_KEX_ECDH_REPLY”

我能够通过强制将IPv4与

ssh -4 username@host.xyz

由于我使用的是Mac，因此我不知道此处的MTU设置或更改方法如何，但我认为其他人可能会从中受益。

我今天在Windows（随Git分发的ssh）和Ubuntu上开始遇到此问题。

它似乎是OpenSSH上的错误，而LauchPad上存在问题。

它在Windows上对我有效，它强制使用3des-cbc密码和Ubuntu上的密钥。

这里有点坏处，但是我在Linux的OpenSSH_7.8p1上遇到过。在最近发布的OpenSSH版本中，DSCP标记的引入似乎在VMware NAT中有所突破（在以下链接中提到桥接网络很好）。

您可以通过在/ etc / ssh / ssh_config中添加/设置以下内容来解决此问题：

IPQoS lowdelay throughput

其他因素可能是PuTTY（或其他不同的SSH客户端）可能不会在同一主机上遇到此问题，并且到目前为止，您的MTU都已签出。即：

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

这些帖子特别有用，使我到达了需要去的地方：

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

ssh -c aes256-ctr工作正常；