SSH 可以在 putty 中工作，但不能在终端中使用

Question

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

当我使用腻子时，我能够连接到服务器。为什么会发生这种情况，我怎样才能让它在终端中工作？

ssh -v 用户名@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

Answer 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

Ciphers 或 HostKeyAlgorithms 都没有独立工作，很确定 MAC 使我处于最重要的位置以使其正常工作，但我不能确定，花了很多时间来解决这个问题。我希望这至少可以帮助其他人。

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

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

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

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

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

Answer 2

这对我有用...

ifconfig eth0 mtu 576

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

Answer 3

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

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

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

Answer 4

做了一些查找，发现了以下建议：

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

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

您还可以尝试将该文件恢复为默认值并重试，即卸载并重新安装openssh-clientIIRC 包的名称。