Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Server drops connection during clone for one client that seems to be authenticated

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


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

 

1 answer

0 votes
Syahrul
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Feb 27, 2023

G'day, @dcorbin13 

This sound similar to the following thread here.

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

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

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PERMISSIONS LEVEL
Site Admin
TAGS
AUG Leaders

Atlassian Community Events