Server drops connection during clone for one client that seems to be authenticated
Asked by dcorbin13:

I have a client that is unable to clone one of my private repos, and I'm unable to solve the problem. I am able to go to two other clients and successfully clone this repo. I have added the SSH key for the client on my personal account. Debugging SSH indicates to me that it is correctly being authenticated. All the machines are behind the same NATed firewall so requests should be coming from the same address. The client in question is running debian bullseye. As part of my debugging, I have upgraded git to the back ported version (2.30 -\> 2.39) but that did not change the problem.

Here is the command I issue:

```
git clone git@bitbucket.org:dcorbin13/restic-support.git
```

And here is the result:

```
Cloning into 'restic-support'...
Connection to bitbucket.org closed by remote host.
fatal: Could not read from remote repository.

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

Note there is about a 20 second delay between the "Cloning into..." line and the failure. My successful clones do not have that delay.

When I run with GIT_SSH_COMMAND="ssh -vvv", it shows

```
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).?
```

After SSH sends some env variables, I see

```
debug1: Sending env LC_TERMINAL = iTerm2
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env PWD
debug3: Ignored env SSH_CONNECTION
debug1: Sending command: git-upload-pack 'dcorbin13/restic-support.git'
debug2: channel 0: request exec confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 2097152 rmax 32768
debug3: receive packet: type 97
debug2: channel 0: rcvd close
```

<br />

I can provide more of the SSH debug output if it is helpful, but I'm pretty sure that's the relevant portion. I'm at a loss for what else I can do. I feel like something in the server side log may hold a key. If anyone does check into log files, my latest attempt is at Sat 25 Feb 2023 12:13:30 PM UTC


Answers:
author: Syahrul
body: G'day, [@dcorbin13](/t5/user/viewprofilepage/user-id/5156307)

This sound similar to the following thread [here.](https://community.atlassian.com/t5/Bitbucket-questions/Can-t-read-from-remote-repository/qaq-p/2239796)

Can you review it and see if that helps?

I suspect your local git is not using the right SSH key, which is why you are getting the following error because the ssh key used to authenticate is invalid:

```
Could not read from remote repository
```

Let me know how it goes.

Cheers,  
Syahrul

comments: author: dcorbin13
body: I went to test this and the problem has resolved itself. I captured the output of

```
 GIT_TRACE=1 GIT_SSH_COMMAND="ssh -vvv" git clone git@bitbucket.org:dcorbin13/restic-support.git
```

so I could compare it against an earlier failing such capture and found this as the only substantive differences before the point of failure:

```
27,28c29,30
< debug1: Remote protocol version 2.0, remote software version conker_2627e95aa5 10916a053a7b^M
< debug1: no match: conker_2627e95aa5 10916a053a7b^M
---
> debug1: Remote protocol version 2.0, remote software version conker_2627e95aa5 3ec1ce4cc7b1^M
> debug1: no match: conker_2627e95aa5 3ec1ce4cc7b1^M
101c103
< debug1: kex_input_ext_info: server-sig-algs=<ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-rsa,ecdsa-sha2-nistp256,ssh-rsa-cert-v01@openssh.com>^M
---
> debug1: kex_input_ext_info: server-sig-algs=<ssh-rsa,rsa-sha2-512,ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@openssh.com,rsa-sha2-256,ssh-dss,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com>^M
```

It looks to me like something changed on the server side


Tags: bitbucket-cloud

cloud