怎么修？ “kex_exchange_identification：读取：对等方重置连接”答案

【问题标题】：How to fix? "kex_exchange_identification: read: Connection reset by peer"怎么修？ “kex_exchange_identification：读取：对等方重置连接”
【发布时间】：2021-11-22 09:36:53
【问题描述】：

我想使用 PRIVATE_KEY 在 GitLab 管道中复制带有 scp 的数据错误是：

kex_exchange_identification: read: Connection reset by peer
Connection reset by x.x.x.x port 22
lost connection

管道日志：

$ mkdir -p ~/.ssh
$ echo "$SSH_PRIVATE_KEY" | tr -d '\r' > ~/.ssh/id_rsa
$ chmod 600 ~/.ssh/id_rsa
$ eval "$(ssh-agent -s)"
Agent pid 22

$ ssh-add ~/.ssh/id_rsa
Identity added: /root/.ssh/id_rsa (/root/.ssh/id_rsa)

$ ssh-keyscan -H $IP >> ~/.ssh/known_hosts
# x.x.x.x:22 SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.10
# x.x.x.x:22 SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.10

$ scp -rv api.yml root@$IP:/home/services/test/
Executing: program /usr/bin/ssh host x.x.x.x, user root, command scp -v -r -t /home/services/test/

OpenSSH_8.6p1, OpenSSL 1.1.1l  24 Aug 2021
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to x.x.x.x [x.x.x.x] port 22.
debug1: Connection established.
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: identity file /root/.ssh/id_ecdsa_sk type -1
debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: identity file /root/.ssh/id_ed25519_sk type -1
debug1: identity file /root/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /root/.ssh/id_xmss type -1
debug1: identity file /root/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.6
kex_exchange_identification: read: Connection reset by peer
Connection reset by x.x.x.x port 22
lost connection

【问题讨论】：

ssh 一个 Asustor NAS 时遇到这个问题。检查/usr/builtin/etc/ipblock/ipblock.deny 以查看是否有任何 IP 被阻止。我认为这有点相当于/etc/hosts.deny。

标签： ssh gitlab-ci pipeline scp sshd

【解决方案1】：

推荐的答案 GitLab

kex_exchange_identification: read: Connection reset by peer

当 ssh 客户端连接到 ssh 服务器时，服务器首先向客户端发送版本字符串。您收到的错误意味着从客户端到服务器的 TCP 连接在客户端等待来自服务器的数据时“异常关闭”，换句话说，在 TCP 连接打开后立即关闭。

实际上，它可能意味着以下两种情况之一：

ssh 服务器进程出现故障（崩溃），或者它可能检测到一些严重问题导致它立即退出。
某些防火墙正在干扰与 ssh 服务器的连接。

看起来 ssh-keyscan 程序能够连接到服务器并获得版本字符串而没有错误。因此 ssh 服务器进程显然能够与客户端通信而不会崩溃。

您应该与这台 x.x.x.x 主机和它所连接的网络的管理员联系，看看他们能否从他们的角度找出问题所在。有可能某些东西——防火墙或 ssh 服务器进程本身——将多个连接视为入侵尝试，首先来自 ssh-keyscan 进程，然后是 scp 程序。它阻止了第二次连接尝试。

【讨论】：

【解决方案2】：

和我一样的问题：

ex_exchange_identification: Connection closed by remote host

试试sudo scp。

【讨论】：

【解决方案3】：

我建议检查路由表的一种可能性。在 Ubuntu20 上，我添加了一个本地网络路由条目，以便在使用 ssh 连接到服务器时收到相同的错误消息时进行恢复。没想到竟然消失了，只剩下默认路由。

user@hostname:~$ route -n Kernel IP routing table Destination     Gateway  
Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 enp1s0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 enp1s0  # <= disappeared

虽然第一个 syn 已通过，但似乎 ack 被不完整的路由表过滤了。

【讨论】：

【解决方案4】：

和我一样的问题：我已经通过以下步骤解决了这个问题

编辑文件"etc/hosts.allow"。命令这样做"sudo nano /etc/hosts.allow"。
最后将 ALL 键的值更新为 ALL，例如 ALL : ALL。保存文件并重试。

基本上 ALL 可能被设置为其他值，因此在建立与主机的 ssh 连接时，预计请求应该来自从 10 开始的 IP。..* 如果 ALL 设置为 @ 987654324@。因此，通过将 10. 替换为 ALL，您可以从任何地方进行连接。

【讨论】：