Having followed this guide
I seem to have setup all the keys needed, but this command
$ ssh -Tv firstname.lastname@example.org
gives me the following:
OpenSSH_8.8p1, OpenSSL 1.1.1l 24 Aug 2021
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to bitbucket.org [22.214.171.124] port 22.
debug1: Connection established.
debug1: identity file /c/Users/myDumbUserName/.ssh/id_rsa type 0
debug1: identity file /c/Users/myDumbUserName/.ssh/id_rsa-cert type -1
debug1: identity file /c/Users/myDumbUserName/.ssh/id_dsa type -1
debug1: identity file /c/Users/myDumbUserName/.ssh/id_dsa-cert type -1
debug1: identity file /c/Users/myDumbUserName/.ssh/id_ecdsa type -1
debug1: identity file /c/Users/myDumbUserName/.ssh/id_ecdsa-cert type -1
debug1: identity file /c/Users/myDumbUserName/.ssh/id_ecdsa_sk type -1
debug1: identity file /c/Users/myDumbUserName/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /c/Users/myDumbUserName/.ssh/id_ed25519 type -1
debug1: identity file /c/Users/myDumbUserName/.ssh/id_ed25519-cert type -1
debug1: identity file /c/Users/myDumbUserName/.ssh/id_ed25519_sk type -1
debug1: identity file /c/Users/myDumbUserName/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /c/Users/myDumbUserName/.ssh/id_xmss type -1
debug1: identity file /c/Users/myDumbUserName/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.8
kex_exchange_identification: read: Connection reset by peer
Connection reset by 126.96.36.199 port 22
I have thoroughly followed this troubleshooter
with no enlightenment. Any suggestions? Greg
Hi @Greg Saveliev and welcome to the community.
Is your computer behind a corporate firewall? The vast majority of TCP resets are due to misconfigured Access Control Lists and Firewalls, which might be rejecting traffic to Bitbucket's IP addresses. If the computer is behind a firewall, my first suggestion would be to ensure that our IPs are whitelisted and port 22 for SSH is open:
Another possible cause may be the higher MTU/MSS values in the packets we receive from your end, you can check the following knowledge base article which includes steps to determine if that's the case, solutions, and workarounds:
Another more rare cause may be due to Anycast Shift, you can read more details in the following community article:
You can try modifying the hosts file on your machine to direct traffic to Bitbucket's legacy IP addresses, which are not anycast to the internet:
and then run the ssh command (If this works, please note that we suggest it as a temporary workaround, as mentioned in the article I linked).
Beginning on April 4th, we will be implementing push limits. This means that your push cannot be completed if it is over 3.5 GB. If you do attempt to complete a push that is over 3.5 GB, it will fail...