我有一个远程位置的服务器。 当使用SSH连接到那台机器时，它连接断开：
Read from remote host XXXX: Connection reset by peer Connection to XXX closed. 我怀疑这是互联网连接的问题，因为ping到那台机器会以随机间隔显示请求超时。 我甚至试图Google也显示请求超时。
我怎样才能确认这是一个互联网问题/什么是实际的错误？
更多信息：
我们的networking和远程networking之间有一个VPN隧道。 所以我可以使用它获得的本地IP之一ssh远程机器。 并以此成功的希望归结于此。
我会build议你使用traceroute命令。 在窗户上，它被缩短为“tracert”
例如，打开命令提示符并input以下内容（-d表示不要执行DNS查找）：
tracert -d <your server ip address>
这会给你一个TCP数据包在到达目标的路上所经历的所有跳跃的列表。 在您超时之前的最后一次成功跳跃会让您知道互联网失败的原因。 这可能是你的wifi，你的ISP或其他东西。
另一个想法是，有时SSH连接可以被丢弃，因为系统认为连接是空闲的，可以放弃它。 这也可能是您的调制解调器的设置。 但是我认为traceroute会给你一个关于失败点的好主意。 如果你从来没有发现traceroute的失败，那么我想说的是，也许有些东西正在积极地抛弃你的空闲连接。 在你的Wifi路由器/ DSL调制解调器等中查看Keep-Alivetypes设置。
但是把你的发现发回来，让我们看看能不能帮你把这件事情弄清楚。
祝你好运。
我build议安装像smokeping 。 这会给你一段时间的统计数据，你可以使用击败你的ISP提供一个体面的服务。
连接到远程计算机时，在您的计算机上运行networking捕获。 当发生断开连接时，请在远程机器的TCP RST（复位）捕获中查找。 如果你发现它，那么问题是远程机器。 如果你不这样做，那么问题就在于两者之间的联系。
在所有的应有的尊重，我不是说每次都失败。 我的意思是，当path中的一个主机不能回应tracert时，这并不意味着这个主机是问题，如果你使用tracert的话，你会看到总是似乎总有一个主机在path上那不回应。
这里的问题是连接间歇性丢失。 如果比使用tracert困难，ping将是一个不错的select。 Ping和tracert是很好的分类级别的工具，但他们不会帮助发现间歇性问题的原因。 Tracert（就像它的名字所暗示的）是一个跟踪远程主机路由的工具，通过它的性质可以告诉你path是否存在。 Tracert不是一个诊断工具，可以告诉你为什么主机没有响应或正在丢弃数据包。 收集该信息的唯一方法是在连接的两端运行networking捕获，并且如果可能的话，在path的每个链路上运行。
如果我运行一个恒定的ping和一个常量tracert到远程主机，并且从远程主机得到一个失败的ping响应，同时在tracert中看到一个中间主机停止响应，这是否意味着那个中间主机是问题？ 不，它不会，现在有办法关联这两个事件，除非我在path中的每个链路上运行networking捕获，并可以在数据包级别分析数据。
我只是build议开始与已知的，可测量的组件，这是在任何一端的两个主机troubleshhoting。
我知道每个人都有自己的意见，我的意图不是发动战争，所以如果有人冒犯我，我很抱歉。
你是否有任何可能限制或限制机器上传入的SSH连接的东西，比如iptables（Linux）或inetd.conf（FreeBSD）？ 如果在重试连接之前等待5或15分钟，会发生什么情况？