ssh 客户端问题：对等方重置连接

Question

我的 Ubuntu 笔记本电脑遇到了一个非常烦人的问题。

在升级到 Ubuntu 11.04 后，我今天注意到了这一点，尽管我不完全确定这是我几天前使用 ssh 密钥的原因。

问题是，每当我尝试通过 ssh 连接到任何主机时，都会出现以下错误：

Read from socket failed: Connection reset by peer

使用 -vvv 运行会产生以下输出：

OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to hostname [10.0.0.2] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_4.2
debug1: match: OpenSSH_4.2 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-1ubuntu3
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "hostname" from file "/root/.ssh/known_hosts"
debug3: load_hostkeys: loaded 0 keys
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer

我的/etc/ssh/ssh_config：

Host *
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication no
    GSSAPIDelegateCredentials no

我可以通过 ssh 从任何其他服务器连接到我的笔记本电脑，我也可以从我的笔记本电脑成功 ssh 本地主机。

我可以从其他笔记本电脑连接到所有这些其他服务器，但我在其他服务器的日志中看不到任何关于我的失败尝试的内容。

我试图停止 iptables，没有帮助。

我尝试了几个我可以用我的/etc/ssh/ssh_config在网上找到的技巧，但我没有成功解决问题......

有任何想法吗？

---

编辑：这是我尝试连接的其中一台主机的日志：

May  1 19:15:23 localhost sshd[2845]: debug1: Forked child 2847.
May  1 19:15:23 localhost sshd[2845]: debug3: send_rexec_state: entering fd = 8 config len 577
May  1 19:15:23 localhost sshd[2845]: debug3: ssh_msg_send: type 0
May  1 19:15:23 localhost sshd[2845]: debug3: send_rexec_state: done
May  1 19:15:23 localhost sshd[2847]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
May  1 19:15:23 localhost sshd[2847]: debug1: inetd sockets after dupping: 3, 3
May  1 19:15:23 localhost sshd[2847]: Connection from 10.0.0.7 port 55747
May  1 19:15:23 localhost sshd[2847]: debug1: Client protocol version 2.0; client software version OpenSSH_5.8p1 Debian-1ubuntu3
May  1 19:15:23 localhost sshd[2847]: debug1: match: OpenSSH_5.8p1 Debian-1ubuntu3 pat OpenSSH*
May  1 19:15:23 localhost sshd[2847]: debug1: Enabling compatibility mode for protocol 2.0
May  1 19:15:23 localhost sshd[2847]: debug1: Local version string SSH-2.0-OpenSSH_5.3
May  1 19:15:23 localhost sshd[2847]: debug2: fd 3 setting O_NONBLOCK
May  1 19:15:23 localhost sshd[2847]: debug2: Network child is on pid 2848
May  1 19:15:23 localhost sshd[2847]: debug3: preauth child monitor started
May  1 19:15:23 localhost sshd[2847]: debug3: mm_request_receive entering
May  1 19:15:23 localhost sshd[2848]: debug3: privsep user:group 74:74
May  1 19:15:23 localhost sshd[2848]: debug1: permanently_set_uid: 74/74
May  1 19:15:23 localhost sshd[2848]: debug1: list_hostkey_types: ssh-rsa,ssh-dss
May  1 19:15:23 localhost sshd[2848]: debug1: SSH2_MSG_KEXINIT sent
May  1 19:15:23 localhost sshd[2848]: debug3: Wrote 784 bytes for a total of 805
May  1 19:15:23 localhost sshd[2848]: fatal: Read from socket failed: Connection reset by peer

Answer 1

在 openssh 中这是一个难以调试的问题，它似乎只发生在特定的客户端到特定的服务器上。

1. 原因？我没有找到根本原因。我最好的发现是连接数据包太大，服务器无法处理，并且连接被重置。

2. 解决方法：限制数据包大小。两种选择：

   • 通过在 ssh 命令行中使用“-c”来限制密码列表长度，例如“-c aes256-ctr”
   • 通过添加到 ~/.ssh/config 来限制 HostKeyAlgorithms 列表：

     HostKeyAlgorithms ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa -sha2-nistp256、ecdsa-sha2-nistp384、ecdsa-sha2-nistp521、ssh-rsa、ssh-dss

3. 网址：

   • Ubuntu 错误：https : //bugs.launchpad.net/ubuntu/+source/openssh/+bug/708493
   • 我在 openssh-unix-dev 列表上的线程：http : //lists.mindrot.org/pipermail/openssh-unix-dev/2011-February/029361.html

4. 受影响的版本：AFAIK 从 5.7p1 开始。降级到 5.5p1 可以解决问题。但是，在没有此问题的机器上，5.7p1、5.8p1 可以完美运行。因此，我的假设是它与在 5.7p1 上添加到第 3 方库的无害库调用有关，该调用仅在某些环境中被破坏。对疯狂错误的疯狂假设。