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

Question

I want to copy data with scp in GitLab pipeline using PRIVATE_KEY error is:

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

pipeline log:

$ 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

Answer 1

kex_exchange_identification: read: Connection reset by peer

When an ssh client connects to an ssh server, the server starts by sending a version string to the client. The error that you're getting means that the TCP connection from the client to the server was "abnormally closed" while the client was waiting for this data from the server, in other words immediately after the TCP connection was opened.

As a practical matter, it's likely to mean one of two things:

1. The ssh server process malfunctioned (crashed), or perhaps it detected some serious issue causing it to exit immediately.
2. Some firewall is interfering with connections to the ssh server.

It looks like the ssh-keyscan program was able to connect to the server and get a version string without an error. So the ssh server process is apparently able to talk to a client without crashing.

You should talk the administrators of this xxxx host and the network that it's attached to, to see if they can identify the problem from their end. It's possible that something--a firewall, or the ssh server process itself--is seeing the multiple connections, first from the ssh-keyscan process, then by the scp program, as an intrusion attempt. And it's blocking the second connection attempt.

Answer 2

I met this issue after I changed my Apple ID password, so I updated my Apple ID and restart my Mac, it works now.

mac:release jianzhang$ git pull origin master
kex_exchange_identification: read: Connection reset by peer
Connection reset by 20.205.243.166 port 22
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Answer 3

I had the same problem. I rebooted the server, then it was all good.

Answer 4

Same issue with me:

ex_exchange_identification: Connection closed by remote host

Try sudo scp .

Answer 5

I suggest to check the routing table for one possibility. In my case on Ubuntu20, I added a local network routing entry to recover when I got the same error message when connecting to the server using ssh. It had disappeared unexpectedly, leaving only the default route.

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

It seemed as if ack was being filtered by an incomplete routing table although first syn passed.

Answer 6

Similar to @naoki-ogawa I had a problem with my routing table in my case I had an extra route for my local network.

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         RT-AX92U-3E20   0.0.0.0         UG    100    0        0 eno1
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 virbr1
192.168.50.0    RT-AX92U-3E20   255.255.255.0   UG    10     0        0 eno1
192.168.50.0    0.0.0.0         255.255.255.0   U     100    0        0 eno1

I simply removed the gateway on the local network (192.168.50.0)

route del 192.168.50.0/24 via 192.168.50.1

Problem resolved.

Answer 7

You can try the VPN or if you have been using it before, try to turn it off and connect it again If you don't have a budget for a VPN, you can try ProtonVPN which is free. It worked for me when I faced the same problem.

Answer 8

Try to check if open ssh server is up and running in the server side. Try checking the sshd config. It worked this way for me. Good luck.

Answer 9

TL;DR: find the server side process listen to ssh port and kill it, then restart ssh service, should solve this problem.

On the client side:

$ ssh account@ip -pPORT
kex_exchange_identification: read: Connection reset by peer

I tried on the server side

$ service ssh status
[ ok ] sshd is running.
$ service ssh restart
[ ok ] Restarting OpenBSD Secure Shell server: sshd.

but the client side ssh command still fail with the same kex_exchange_identification error

then I stop ssh service on the server side

# service ssh stop
[ ok ] Stopping OpenBSD Secure Shell server: sshd.

and the following client side ssh command still fail with the same kex_exchange_identification error, it's strange, if no process listen the PORT, it should be the error Connection refused

it could be the process on the server side listen to ssh PORT is dead, even a restart / stop service do not work. so to find the process, and kill it may solve the problem.

the PORT here is ssh Port defined in server /etc/ssh/sshd_config, default is 22
# netstat -ap | grep PORT
tcp        0      0 0.0.0.0:PORT            0.0.0.0:*               LISTEN      
8359/sshd
tcp6       0      0 [::]:PORT               [::]:*                  LISTEN      
8359/sshd
# kill 8359
# netstat -ap | grep PORT
no result
# service ssh start
[ ok ] Starting OpenBSD Secure Shell server: sshd.
# netstat -ap | grep PORT
tcp        0      0 0.0.0.0:PORT            0.0.0.0:*               LISTEN      31418/sshd: /usr/sb
tcp6       0      0 [::]:PORT              [::]:*                  LISTEN      31418/sshd: /usr/sb

the following client side ssh command succeed.

Answer 10

For those who came across this page after upgrading a FreeBSD machine to 13.1 and then trying to ssh into it, see https://bugs.freebsd.org/bugzilla//show_bug.cgi?id=263489 . After the upgrade, the previous sshd daemon (OpenSSH < 8.2) is still running with new configs (OpenSSH >= 8.2). The solution is to stop and then restart the sshd daemon. The FreeBSD 13.1 release notes now mention this and after 13.1, the freebsd-update script will automatically restart the daemon.

Answer 11

I had this error today when I was trying to use my Dell Laptop running Description: Ubuntu 20.04.5 LTS and trying to SSH into a Raspberry Pi. When I was on my Home Wifi.network and tried to SSH into the pi (also on my home wifi.network) I got the error: `$ ssh pi@10.0.0.200 kex_exchange_identification: read: Connection reset by peer'

However, when I switched my Ubuntu Laptop over to a mobile hotspot, the error disappeared, and I was able to SSH without issue. Will update this post as soon as I figure out how to resolve the root cause.

EDIT: Issue resolved (but full reason unclear). I followed the instructions to change my DNS server here to 8.8.8.8 and 8.8.4.4.

After about 5 mins had elapsed, I was able to use SSH from my command line terminal just fine.

Answer 12

Error

kex_exchange_identification: read: Connection reset by peer Connection reset by xxxx port 22

I have an Ubuntu 20.04 host and 2 rhel8 VMs running on VMware. I login into the 2 VMs from my ubuntu terminal. I use ethe.net and WiFi connections. Every time I try to login into a VM after rebooting it I get the error:

Restarting the sshd service will not solve the problem. Sometimes, the problem would be resolved if I physically disconnected and reconnected the ethe.net cable.

Finally I turned off my WiFi connection with: nmcli conn down <name_of_wifi_connection> or turning it off from settings and this gave me a permanent solution.

Both my ethe.net and wifi connections (static connections) had the same ip address so I think the VMs were rejecting 2 "suspicious" similar connections.

Answer 13

Same issue with me: I have fixed the issue by doing below steps

1. edit file "etc/hosts.allow" . Command to do so "sudo nano /etc/hosts.allow" .
2. At end update value of ALL key to ALL like ALL: ALL . Save the file and try again.

Basically ALL might be set to something else therefore while establishing ssh connection to the host, it is expecting that the request should come from the IP starting from 10. . .* if ALL set to ALL: 10. . Therefore by replacing 10. with ALL, you are allowing connection from everywhere.