kex_exchange_identification: read: Connection reset by peer

[emvoo]

Some clients (so far macos but not sure if this is a rule yet) cant establish connection due to error

kex_exchange_identification: read: Connection reset by peer

[asimrp]

I'm seeing this same issue on MacOS 10.15 with tmate version 2.4.0. In case it helps solve the problem, the output of ssh -vvv is as follows (it doesn't make much sense to me):

ssh -vvv  <tmate session_ID>@sfo2.tmate.io
OpenSSH_8.1p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/apraveen/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 47: Applying options for *
debug1: Connecting to sfo2.tmate.io port 22.
debug1: Connection established.
debug1: identity file /Users/apraveen/.ssh/id_rsa type 0
debug1: identity file /Users/apraveen/.ssh/id_rsa-cert type -1
debug1: identity file /Users/apraveen/.ssh/id_dsa type -1
debug1: identity file /Users/apraveen/.ssh/id_dsa-cert type -1
debug1: identity file /Users/apraveen/.ssh/id_ecdsa type -1
debug1: identity file /Users/apraveen/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/apraveen/.ssh/id_ed25519 type -1
debug1: identity file /Users/apraveen/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/apraveen/.ssh/id_xmss type -1
debug1: identity file /Users/apraveen/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.1
kex_exchange_identification: Connection closed by remote host

[jiezhang917]

Same issue here

[felixdollack]

Same for me on MacOS 12.1. But I also see this message trying to connect from an Ubuntu setup

ssh -vvv  <tmate session_ID>@sfo2.tmate.io
OpenSSH_8.2p1 Ubuntu-4ubuntu0.3, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolving "sfo2.tmate.io" port 22
debug2: ssh_connect_direct
debug1: Connecting to sfo2.tmate.io [157.230.72.130] port 22.
debug1: Connection established.
debug1: identity file /home/felix/.ssh/id_rsa type -1
debug1: identity file /home/felix/.ssh/id_rsa-cert type -1
debug1: identity file /home/felix/.ssh/id_dsa type -1
debug1: identity file /home/felix/.ssh/id_dsa-cert type -1
debug1: identity file /home/felix/.ssh/id_ecdsa type -1
debug1: identity file /home/felix/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/felix/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/felix/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/felix/.ssh/id_ed25519 type 3
debug1: identity file /home/felix/.ssh/id_ed25519-cert type -1
debug1: identity file /home/felix/.ssh/id_ed25519_sk type -1
debug1: identity file /home/felix/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/felix/.ssh/id_xmss type -1
debug1: identity file /home/felix/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.3
kex_exchange_identification: Connection closed by remote host

[KamilLelonek]

Same here for me. It finishes with:

debug1: Local version string SSH-2.0-OpenSSH_8.6
kex_exchange_identification: read: Connection reset by peer
Connection reset by 157.230.72.130 port 22

[mattalxndr]

I'm getting the same error on Arch Linux:

% tmate -V
tmate 2.4.0
% ssh h4uqkLJ85WXghc3GPESjWDzuJ@sgp1.tmate.io
kex_exchange_identification: read: Connection reset by peer
Connection reset by 188.166.207.127 port 22

[lucidheart]

Sad to see that there's not been any follow up or solution to this post. I have recently run into this problem while sshing from Ubuntu 20.04.5 into our Synology device. ssh on the Synology works fine from my Windows box, and internally to/from itself. However, when coming from the Ubuntu 20.4.5 system, the Synology resets the connection.

I've dug a little deeper, in running a packet capture, and it seems that the server (Synology) is resetting the connection after it receives a packet of data containing the version information from Ubuntu. That string is "SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.5"

There's some binary data in the packet before that string, but I'm not sure what that binary data is. Synology/server responds with an ACK. And then shortly after with a RST, ACK to reset the connection.

I'm flirting with the idea of downgrading ssh on Ubuntu 20.04.5 to see if that at least gets it working. Though, it would sure be nice to understand better what's going on.

[lucidheart]

ugh. After so many hours, it appears that the client IP was listed in the Synology blacklist for the firewall. Sorry for the unnecessary noise. Seems to always happen that I find the solution only moments after posting online about it. So typical. :-P