Click here to Skip to main content
15,887,135 members
Please Sign up or sign in to vote.
1.00/5 (1 vote)
See more:
Hi forum,

I'm using TortoiseGit for several years now along with the occasional Git Gui for including just a few lines of changes in a commit.

A few days ago, I had to push some of our repositories to a remote location for backup. That place runs BitBucket. I have been shown a directory where I should create subdirectories for the repositories to push. And then some credentials and a VPN client to connect all that together.

When the VPN was working, I fired up PuttyGen and created a pair of SSH keys on my development machine and put the public key in that BitBucket SSH key store. I set the first one of my local repositories to have another remote that points there and use the respective SSH key (the private one).
But I haven't been able to push, fetch, clone or whatever to/from that remote ever since.

Instead I get something like that:
git.exe fetch -v --progress "origin"
OpenSSH_8.4p1, OpenSSL 1.1.1h  22 Sep 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolve_canonicalize: hostname 192.168.10.28 is address
debug2: ssh_connect_direct
debug1: Connecting to 192.168.10.28 [192.168.10.28] port 22.
debug1: Connection established.
debug1: identity file /c/Users/MyName/.ssh/id_rsa type -1
debug1: identity file /c/Users/MyName/.ssh/id_rsa-cert type -1
debug1: identity file /c/Users/MyName/.ssh/id_dsa type -1
debug1: identity file /c/Users/MyName/.ssh/id_dsa-cert type -1
debug1: identity file /c/Users/MyName/.ssh/id_ecdsa type -1
debug1: identity file /c/Users/MyName/.ssh/id_ecdsa-cert type -1
debug1: identity file /c/Users/MyName/.ssh/id_ecdsa_sk type -1
debug1: identity file /c/Users/MyName/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /c/Users/MyName/.ssh/id_ed25519 type -1
debug1: identity file /c/Users/MyName/.ssh/id_ed25519-cert type -1
debug1: identity file /c/Users/MyName/.ssh/id_ed25519_sk type -1
debug1: identity file /c/Users/MyName/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /c/Users/MyName/.ssh/id_xmss type -1
debug1: identity file /c/Users/MyName/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.2p1 Debian-2+deb12u2
debug1: match: OpenSSH_9.2p1 Debian-2+deb12u2 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.10.28:22 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
There's more but let's first get to this.

I gave TortoiseGit the exact file with the private key. Why is it testing so many (non-existent) keys, all returning -1?

Some time into this investigation, I had to push something onto our in-house GitLab instance. This is now showing the exact same log as above, wich it hasn't done in the past. And pushing did fail. It closes with the lines
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
debug1: read_passphrase: requested to askpass
debug2: we sent a password packet, wait for reply
Connection closed by 192.168.10.28 port 22
fatal: Could not read from remote repository.

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


git did not exit cleanly (exit code 128) (172000 ms @ 04.03.2024 12:14:15)


What I have tried:

Created new key pair.
Moved my key into the above given location and renamed to id_rsa.
Edited ~/.ssh/config to include a new host with my key.
Posted
Comments
Andre Oosthuizen 6-Mar-24 14:52pm    
'Please make sure you have the correct access rights
and the repository exists.' - someone changed some settings or passwords somewhere...
lukeer 11-Mar-24 4:02am    
Doesn't seem so. But four days ago, that was a possible cause.

1 solution

I did not find out what originally caused the problem.

At least this works:
- Remove TortoiseGit and Git
- Install current version of Git and this time without the optional OpenSSH.
Use Windows' OpenSSH instead
- Install current version of TortoiseGit
Use OpenSSH's ssh agent instead of the previously used pagent.exe (Putty Agent).
- Convert PuttyGen's private keys to OpenSSH format
- edit %userprofile%\.ssh\config to contain
- one section for the local GitLab server to refer to the OpenSSH-compatible private key
- one section for the remote Git repository server to refer to an OpenSSH-compatible private key

I still don't know why the TortoiseGit-Git-SSH compound ignores the private key setting for a given repository's remote setting and uses the SSH config instead.
I'm not yet satisfied with the SSH agent state that I have to start the agent once every boot (C:\>eval $(ssh-agent)) and have to load the keys into it (C:\>ssh-add keyfile.prv) or unlock the key for every single usage. But at least I have it working at all.
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900