【问题标题】:SSH "kex_exchange_identification: read: Connection reset by peer"SSH“kex_exchange_identification:读取:对等方重置连接”
【发布时间】:2020-07-25 21:15:38
【问题描述】:

设置:

  • Raspberry 3B 在外部 HDD 上运行 Raspbian Stretch 9 并使用 ZRAM
  • Raspi 用作运行 LAMP 和 MERN 堆栈的网络服务器,并通过 SSH 和 1 个 IDE(Coda for Mac OS)远程访问
  • 静态 IP 路由器转发的 SSH 端口
  • fail2ban 运行

问题:

当通过 SSH 从远程位置(通过 Internet)访问树莓派时,它会一直工作,直到连接挂起。这是随机发生的。 有时我可以在几分钟后再次 SSH,有时直到我重新启动 Raspi。

我的尝试:

  • 从远程位置以详细模式进行 SSH:
debug1: Local version string SSH-2.0-OpenSSH_8.1
kex_exchange_identification: read: Connection reset by peer
  • 从本地网络以详细模式进行 SSH(我实际上是远程 SSH 本地网络上的另一台机器,然后从那台机器 SSH Raspi)。 结果相同Connection reset by peer
  • 检查了/etc/hosts.allow/etc/hosts.deny => 什么都没有
  • 通过 iptables -L --line-number 检查 iptables => 那里什么都没有
  • 检查的日志:/var/log/fail2ban.logsudo journalctl -t sshd => 没有什么特别的地方
  • sshd_config 更新为no DNS
  • 通过apt-get --reinstall install openssh-server openssh-client重新安装SSH

我的想法已经不多了,也不知道发生了什么。 之前有人遇到过与 SSH 连接相同的问题吗? 会不会是树莓派的负载问题?

【问题讨论】:

  • 客户端重启对我有用

标签: ssh raspberry-pi ssh-keys openssh fail2ban


【解决方案1】:

长话短说,我的问题与网络问题无关,通过检查 syslog 已解决。

详细说明:

我注意到在问题开始之前启动并运行的所有 web 应用程序(通过 LAMP 或 MERN 堆栈)都无法再访问。

所以我使用tail -f -n X /var/log/syslog 命令(将X 替换为您要显示的行数)挖掘了系统日志。 然后我注意到几行提到电压问题(抱歉,我确实保留了确切的条款)。但基本上这意味着我的外接硬盘插入的Raspi没有足够强大的电源。

然后看起来硬盘被卸载并且系统崩溃了,这解释了上面提到的所有问题。

所以我移除了 HDD 将 SD 卡放回原处并再次运行 Raspi,同时再次查看 syslog 并使用 htop 监控内存。事实证明,当我同时启动 apache 和节点服务器时,RAM 和 SWAP 内存已满,重复上述相同的后果。

所以最后我通过使用 ZRAM 增加了 SWAP 内存。 Link here.

现在一切运行良好,但仍在监控。

【讨论】:

    【解决方案2】:

    我发现了导致这个精确错误的另一种情况。请务必检查您尝试使用 SSH 连接的主机系统上 /etc/ssh 中 OpenSSH 生成的公钥/私钥文件的权限。这些密钥由 SSH 守护程序使用。

    由于 OpenSSH 是跨平台的,因此同样适用于任何运行 SSHd 的操作系统。这些文件必须具有适当的权限。

    /etc/ssh 是默认路径,但如果您使用的是 Windows 或其他操作系统,它可能会有所不同。但对于大多数 Unix/Linux/macOS 系统,它应该是 /etc/ssh。

    sudo chmod 600 *_key
    sudo chmod 644 *.pub
    

    您还应该验证 SSH 客户端对 ~/.ssh 和公钥/私钥、配置、授权密钥等是否具有正确的权限。尽管如果这些错误,您会立即被告知。但是,当 SSH 守护程序的密钥权限错误时,您会在日志中收到错误消息。

    当它不是 DNS 或证书时,它总是权限。

    【讨论】:

      【解决方案3】:

      我没有看到安装了 ufw(防火墙)。

      ufw disable

      (Or configure ufw.)
      

      现在端口可以按预期访问了。

      【讨论】:

      • 接受的答案实际上帮助了我,因为它让我想到了运行 journalctl -e 而不搜索“sshd”。就在那时我看到 ufw 阻止了我的连接。
      猜你喜欢
      • 2021-11-22
      • 1970-01-01
      • 2016-01-14
      • 2021-07-15
      • 1970-01-01
      • 1970-01-01
      • 2015-07-09
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多