TortoiseGit asking for password on password-less login setup

Question

After months of uninterrupted password-less work, my TortoiseGit started to ask me for a password on some of my remotes, when pushing / pulling. I'm seeking a solution to fix this, as this can drive me crazy.

To underline: I want to remain on SSH-based password-less login, so any solutions that assume adding password to URL or permanently storing password in TortoiseGit configuration is not an option for me.

What I found out so far:

1. My problem is not related to GitHub; I don't use it in TortoiseGit and it happens on other remotes.

2. I do have SSH, not HTTPS, address as repo's URL and I don't have git clone-like stuff in it.

3. I can push/pull the same repository using Netbeans (and my Netbeans has Select Configured Git Repository Location option checked, so it uses the same remote configuration).

4. I can't push/pull remote using Git GUI, reason the same: asking for user password.

5. This is not related to a particular system or machine (SSH key), as it happens on both my work computer (32-bit Win 7) and home one (64-bit Win 7). Both of course uses different SSH key (see comment to this answer, which claims, that problem is related to 32-bit version of Windows; this is not true, it happens on 64-bit Windows as well).

6. Repository, this happens on, isn't empty -- I heard and even been personally affected, that sometimes TortoiseGit gets wako and asks for password on password-less login remote, until that remote is empty.

7. This is not related to a particular remote -- TortoiseGit works fine, without asking for password on some repositories (i.e. BitBucket) but "dies" asking for it on some other (i.e. in local dev network).

To make things even worse, there are certain remotes, on which TortoiseGit on my home computer fails, asking for password, while the very same remote accessed from home computer works just fine. And vice-versa. I set both machines for password-less login using the same steps; only SSH keys differs.

Things I did so far (and didn't solve the problem):

1. Changing SSH client (TortoiseGit -> Settings -> Network) to both Git\bin\ssh.exe (as suggested in here) and to C:\Program Files\PuTTy\plink.exe.

2. Using credential helper doesn't helped and I heard that it works for HTTPS only, not for SSL.

3. Downloading git-credential-wincred.exe and putting it to Git for Windows / msysgit folder didn't help as well; I've already had it there (different version / filesize; checked on both).

4. This issue is clearly bind to asking for user password, so git did not exit cleanly (exit code 128) error following it doesn't have any other source except missing password and most solutions given here, like crashed git, locked file, missing user e-mail are not solution for me.

OK, that's the farest point I've reached. And still nothing. Can anyone come up with something new, that I should try to solve this issue?

Answer 1

I confirm that "storing password" or _netrc file, or any credential helpers are for https url only, and have nothing to do with SSH.

The usual debugging ssh steps apply, starting by making sure that %HOME% is defined when TortoiseGit is launched, and %HOME%/.ssh exists, and contains the default keys id_rsa and id_rsa.pub.

In a git bash session, you can do a ssh -Tvvv yourRemoteServer to see what the debug error message sequence is, as explained here.

You also can check the result of a GIT_TRACE=2 git push test master, to see if the issue is limited to TortoiseGit and if the verbose output leaves any clue (see here).
Try switching ssh client between putty and openssh to see if TortoiseGit fairs better with one or the other.

Answer 2

The issue appeared yesterday and it took me 2-3 hours of trying all sorts of stuff to fix it. I also contacted server administrator, who claimed not to have done any changes in config in the past days. Hence I put bounty on this question. I also gave it a try today, but still negative. Finally, right now, I made another attempt just to copy the message to my friend, and, all of the sudden, all my repos started to work!

I am absolutely sure I didn't touch configs, it must have been some sort of timeout which took more than 16 hours. I have no idea what the problem was. All I can conclude is that waiting till the next day might help...