☰

SSH 在 Putty 中有效，但在终端中无效

tag-icon • tag-icon linux ssh terminal putty
SSH 在 Putty 中有效，但在终端中无效

当我尝试在终端中 ssh 时：出现以下错误：ssh [email protected]
Connection closed by 69.163.227.82

当我使用 putty 时，我能够连接到服务器。为什么会发生这种情况？我该如何在终端中让它工作？

SSH-V[电子邮件保护]

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

答案1

通过以下 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

无论是密码还是 HostKeyAlgorithms 都无法独立工作，我确信 MAC 让我付出了巨大的努力才让这个工作正常进行，但我不能确定，我花了很多时间才解决这个问题。我希望这至少能帮助别人。

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

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

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

必须手动将 MTU 设置为较小的数字以确保不发生碎片，这并不清洁工（作为用户，我们不应该手动采取措施来解决由我们的网络团队造成的问题）......但它至少以可靠和可证明的方式直接处理实际原因，而不是以一种副作用的方式搞砸 SSH 的密码设置，当星星排成一行时，恰好导致它无法生成大数据包。

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

答案2

这对我有用...

ifconfig eth0 mtu 576

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

答案3

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

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

您可以阅读有关问题和解决方案的更多信息这里和这里。

答案4

更改网络接口 MTU 即可解决。这是 ubuntu 14.04 的一个 bug。

这对我有用：

sudo ip li set mtu 1200 dev wlan0

或者：

sudo ifconfig wlan0 mtu 1200

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

相关内容