cannot clone cloud-init: read from socket failed: connection reset by peer

Asked by Michael Felt

I do not think this is specific to cloud-init - that project is just the example.

In their documentation they state the way to clone using git is:

git clone <email address hidden>:cloud-init

When I omit USERID I get the message:

Launchpad user 'michael' doesn't have a registered SSH key

When I include USERID I start with:
Cloning into 'cloud-init'...

and after 120 minutes I get:
Read from socket failed: Connection reset by peer
fatal: Could not read from remote repository.

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

So, maybe it is cloud-init, and the access rights are not permitting the clone, or maybe my SSH key is not correct.

I could not find a way to verify the SSH keys are handshaking as expected so I am hoping (not assuming) that since there is no message about 'USERID' doesn't have a registered key - something positive is happening with that part.

Your suggestions are welcome!

Michael

p.s. a git clone .... from github works with no issues.

Question information

Language:
English Edit question
Status:
Solved
For:
Launchpad itself Edit question
Assignee:
No assignee Edit question
Solved by:
Michael Felt
Solved:
Last query:
Last reply:
Revision history for this message
Michael Felt (aixtools) said :
#1

Maybe it was a typo...

Working:
git clone git+ssh://<email address hidden>/cloud-init

After changing my name to aixtools, and loading a new ssh-key - also working:
git clone git.launchpad.net:cloud-init

And, as another user - using the a copy of of the new ssh key, using:
git clone <email address hidden>:cloud-init aka git clone <email address hidden>:cloud-init

is working, so I must assume that as there was a key - I was not sending the correct "private" key, and that was the 2 hour delay.

So, for me - the problem is solved - verify ssh keys handshake - i.e., make sure the public key stored relates to a (default) private key.
However, in case anyone notices - having a shorter timer AND a message indicating the SSH/SSL handshake is not completing could help identify the issue much earlier.