我正在运行一个脚本，通过SSH发送远程命令到less数产品盒。 有RSA密钥用于用户连接到这些盒子，在大多数情况下没有问题。 间歇性地，我得到连接超时，可能每20个连接一次。
我使用SSH2作为协议，主要是因为SSH2在我连接的所有机器上都可用。 这是debugging输出的样子，直到连接挂起然后closures。
[mike@dev ~]$ ssh -v -o "Protocol=2" 10.60.###.### "w" OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to 10.60.###.### [10.60.###.###] port 22. debug1: Connection established. debug1: identity file /home/mike/.ssh/id_rsa type 1 debug1: identity file /home/mike/.ssh/id_dsa type -1 debug1: loaded 2 keys debug1: Remote protocol version 1.99, remote software version OpenSSH_3.9p1 debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc 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 10.60.###.### 连接挂在这里，然后closures。
在某些情况下，连接进一步得到了一点，但是又一次挂起。
... debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent Connection closed by 10.60.###.###
服务器的日志结束这样的事情，在连接死亡的情况下：
Jul 23 16:53:07 host02 sshd[4989]: debug1: Client protocol version 2.0; client software version OpenSSH_4.3 Jul 23 16:53:07 host02 sshd[4989]: debug1: match: OpenSSH_4.3 pat OpenSSH* Jul 23 16:53:07 host02 sshd[4989]: debug1: Enabling compatibility mode for protocol 2.0 Jul 23 16:53:07 host02 sshd[4989]: debug1: Local version string SSH-1.99-OpenSSH_3.9p1 Jul 23 16:53:07 host02 sshd[4990]: debug1: permanently_set_uid: 74/74 Jul 23 16:53:07 host02 sshd[4990]: debug1: list_hostkey_types: ssh-rsa,ssh-dss Jul 23 16:53:07 host02 sshd[4990]: debug1: SSH2_MSG_KEXINIT sent Jul 23 16:53:07 host02 sshd[4990]: debug1: SSH2_MSG_KEXINIT received Jul 23 16:53:07 host02 sshd[4990]: debug1: kex: client->server aes128-cbc hmac-md5 none Jul 23 16:53:07 host02 sshd[4990]: debug1: kex: server->client aes128-cbc hmac-md5 none Jul 23 16:53:40 host02 sshd[4990]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received Jul 23 16:53:40 host02 sshd[4990]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent Jul 23 16:53:40 host02 sshd[4990]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT Jul 23 16:53:40 host02 sshd[4990]: Connection closed by ::ffff:192.168.1.203
我发现一台服务器，我一直在testing，如果我使用SSH1，我没有看到任何失败的连接。 但是我想知道是否可以修复SSH2，而不必在所有的生产机器上打开SSH1。
在100个连接尝试中…
使用SSH1： 100连接成功。 使用SSH2：约。 5个连接失败。
有什么（容易）我失踪？
几个星期前我们终于搞定了，值得跟进。 我们从我们的本地办公室路由器运行VPN到我们的数据中心的防火墙，都是思科。 我们更新了路由器和防火墙上的IOS，这似乎已经成功了。
感谢所有提交的想法/答案。
这可能是一个DNS查找问题？ 你的客户的IP在DNS中注册了吗？ 也许超时发生在第一次查找，然后caching了一会儿。
查看连接失败的TCP数据包。 两个日志条目之间的33可能是底层连接丢包或临时失败的结果。 当VPN网关尝试重新build立隧道时，实际上可能会“死亡”。 在没有TCP端点注意的情况下，数据包将丢失。
只需运行tcpdump -i eth99 -s 0 -w ssh2-problem.pcap port 22并且连接失败。 然后使用Wireshark来检查转储文件。 tcp.flags.syn == 1 and tcp.flags.ack == 0的显示filter只提供TCPstream的第一个数据包。 然后使用上下文菜单中的“Follow TCP stream”，closures对话框并查看失败的TCPstream数据包。 任何过度（>> 1）重传？