-v进行调试。输出如下所示。如果我将ssh放入另一个框，然后从该框SSH到服务器，则可以登录。我不知道如何调试此问题，但想学习。 $ ssh -v me@server
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug1: Connecting to server [IP] port 22.
debug1: Connection established.
debug1: identity file /Users/me/.ssh/id_rsa type 1
debug1: identity file /Users/me/.ssh/id_rsa-cert type -1
debug1: identity file /Users/me/.ssh/id_dsa type -1
debug1: identity file /Users/me/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: read: Connection reset by peer
到目前为止（根据留言板的建议），我一直在寻找主机拒绝文件-但我的机器上没有这样的文件。
$ cat /etc/hosts.deny
cat: /etc/hosts.deny: No such file or directory
我在客户端计算机上具有管理员访问权限，但在服务器上却没有。
#1 楼
突然的更改可能是服务器sshd配置上的配置文件更改的结果，但是您表示没有管理员权限就无法检查或更改该配置文件。如果无法及时联系到服务器的管理员，您仍然可以尝试以下操作。您的日志仅指示本地版本字符串，应检查服务器和中间计算机上运行的
sshd的版本。如果这些版本不同（尤其是在本地计算机和服务器之间，而在中间计算机和服务器之间有所不同），则可能存在一些协商不兼容，这在
ssh中已经发生过。解决方案过去是在命令行（ssh -c aes256-ctr等）或/etc/ssh/ssh_config上缩短密码，HostKeyAlgorithms和/或MAC条目。 您应该在调试信息中（通过中间件连接到服务器）查找适当的值，作为
-c / Ciphers，-o HostKeyAlgorithms / HostKeyAlgorithms和-m / MACs命令行参数的参数。 ssh_config更改了。我已经有一段时间没有这个问题了，但是当我执行IIRC时，它足以手动强制Ciphers和HostKeyAlgorithms设置，此后，我可以更新服务器的
sshd版本和问题消失了。评论
就我而言，服务器sshd软件包已更新到新版本，并导致与您当前所说的我当前的ssh客户端配置不兼容。清除我的旧ssh配置文件就可以了。这应该是公认的答案。
–chakrit
2014-09-27 9:40
@chakrit如何清理旧的ssh配置文件？
–乔纳森
17年1月7日在15:12
@Jonathan我安装了恢复盘来执行此操作。
–chakrit
17年1月10日在6:53
@chakrit：如果您可以共享更改的确切设置，那将非常有用。
– Dan Dascalescu
19年11月25日在6:28
#2 楼
您可能已被fail2ban或denyhosts禁止。在这种情况下（并进行检查），如果您不想打扰服务器提供商的帮助，则需要从另一个IP地址登录到服务器： 登录后，检查IP地址是否确实出现在
/etc/hosts.deny（在服务器端）上。如果是这样，则fail2ban或denyhosts确实确实是罪魁祸首。有关防止
denyhosts连续阻止您的地址的过程，请参阅此问题的答案。对于fail2ban，找到带有iptables -L --line-number的IP并取消禁止带有iptables -D <chain> <chain number>的IP，请检查howtoforge的详细信息。您可能希望将IP地址添加到
fail2ban和denyhosts白名单（分别为/etc/fail2ban/jail.conf，ignoreip和/var/lib/denyhosts/allowed-hosts ，请在需要时创建它（但要注意，您的发行版上的路径可能不同），以防止问题再次发生。#3 楼
在主机服务器上，删除位于以下位置的ssh pub.key：适用于Mac的~/.ssh/authorized_keys。然后在打开另一个终端时尝试tail -f /var/log/auth.log并尝试再次ssh ssh -v me@server。如果提示您输入密码，则说明您的ssh密钥有问题。如果仍然看到“ ssh_exchange_identification：读取：连接被对等方重置”响应，则尝试失败后，您应该能够从“ /var/log/auth.log”文件中的日志条目中识别出问题所在。登录。如果仍然无法连接，请从auth文件中发布记录的条目，然后我将修改答案。
评论
在某些情况下，无需删除SSH密钥。直接转到tail -f /var/log/auth.log并检查最近的尝试。
–杰克·罗布森（Jack Robson）
17年11月29日在13:58
#4 楼
如果网络上有多台具有相同MAC地址的计算机（例如，如果您创建虚拟机的副本而忘记更改MAC），则会发生这种情况。#5 楼
我面临着同样的问题。我将成功打开ssh会话，但一段时间后它将重置。当我尝试立即连接增益时，会出现错误“连接被拒绝”。调试会话时，在重置连接时收到此消息
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)
debug3: channel 0: close_fds r 4 w 5 e 6 c -1
Read from remote host 10.x.y.z: Connection reset by peer
Connection to 10.x.y.z closed.
debug1: Transferred: stdin 0, stdout 0, stderr 100 bytes in 1029.9 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.1
debug1: Exit status -1
此时，我意识到存在一个IP地址网络上发生冲突。我改为另一个地址，问题已解决
#6 楼
由于/etc/resolv.conf中ISP的名称服务器，我得到了这个。这些名称服务器经常过载，如果反向DNS查找失败，则sshd将断开连接。我通过使用更可靠的名称服务器来解决了这个问题，例如8.8.8.8。#7 楼
您的日志表示服务器端断开了连接。要找出原因，您应该查阅服务器端日志，这些日志应显示断开连接的原因。您应该几乎总是能够在/ var / log / messages中找到日志我可以猜测，由于客户端发送版本号后连接断开，服务器以某种方式威胁到客户端不兼容。
#8 楼
由于未在“答案”中明确提及，因此出现此错误的另一种方式是，如果您和服务器之间的基于网络的防火墙决定阻止连接。防火墙可能已经确定OS X系统IP的连接“太多”，并开始阻止它。另一个系统还没有“太多”的连接，因此已被允许。从服务器收到的最后一条消息是在甚至开始任何身份验证尝试之前发生的一条消息，该规则排除了围绕您的帐户，密钥或密码的各种可能性。
从供应商中随机抽取的此类强力策略示例如下：
CloudFlare：如何使用速率限制来防御暴力攻击？
F5：配置暴力攻击保护
FortiNet：创建自定义IPS签名以检测模式速率-示例以检测暴力攻击
帕洛阿尔托：防止蛮力攻击
Sonicwall：如何使用SRA阻止蛮力和字典攻击
#9 楼
我遇到了同样的问题，但结果却是不同的：我使用了错误的端口。在新版本的
ssh上给出的错误是Connection refused或Bad port。在较旧的版本给出的错误是
ssh_exchange_identification: read: Connection reset by peer ，所以当您收到此类错误时，请检查端口是否正确。
#10 楼
我知道这个问题很古老，但是我想分享一些发现。检查服务器上的/var/empty/sshd是否具有适当的所有权和权限。我们对Chef脚本进行了修改，以更新某些目录权限，但是无意中更新了预期目标下的目录，从而将/ var的所有权更改为应用程序用户/组并将权限更改为775。
#11 楼
尝试通过Android设备（Huawei P30 Pro）上的Wi-Fi网桥选项连接到我的所有远程主机时遇到此确切错误。当我使用USB共享选项共享同一Internet连接时，没问题。客户端或服务器上的SSH配置或选项完全没有其他改变。
TL ; DR：有时候，您无能为力。
评论
我建议您在备用端口上开始sshd侦听，输出详细，并在尝试连接时提供输出。 $（which sshd）-d -p 23.如果您没有能力执行此操作，那么您的选择将非常有限。最好的选择是让某个拥有服务器管理员权限的人。可能是服务器上的管理员出于某种原因限制了您的访问权限？无论如何，我可能会联系该人。
应该在服务器上而不是在客户端上检查hosts.deny和hosts.allow文件。另外，应检查服务器上的系统日志。如果您也没有访问权限，则可能需要与服务器管理员联系以进行查看。
您找到解决方案了吗？有什么问题吗？
是一个由管理员使用自动脚本填充的hosts.deny列表。由于我在某个时候忘记了密码，因此尝试登录几次失败，这是将我的IP放置在hosts.deny列表中的时候。极大地提高了过度安全性的生产率。