1

I've been dealing with my GIT credentials being deleted from Windows Credential Manager in ~24h. I'm using the latest version of GIT as of today (12/22 - 2.29.2), but I don't even know if the deletion is being triggered by GIT Credential Manager (Core) itself or something else.

This is what I observed so far:

Whenever I run a GIT command for the first time in the day (let's say a GIT PULL), a PAT (Personal Access Token) is created. It expires in a year. In the example below, I am using ADO (Azure DevOps) as my repo:

PAT created by GIT

If I launch Windows Credential Manager (Control Panel\All Control Panel Items\Credential Manager) I see this:

Windows Credential Manager

However, in ~24h this stored credential will be gone and I will be prompted to authenticate again, which is pretty annoying. Any clue on what could be causing this?

This is what I have in my SYSTEM gitconfig file - which came automatically with the installation of GIT:

gitconfig

Any idea about how to avoid the credentials being deleted I will highly appreciate!

Thanks!

Jonathan
  • 59
  • 1
  • 4
  • Hi @Jonathan. You could refer to the troubleshooting steps in the answer and check if they could make some changes. I just upgraded my git version to 2.29.2. So for the time being, it has not had the same problem.I will continue to try to reproduce this issue(After 24 hours). – Kevin Lu-MSFT Dec 23 '20 at 07:14
  • Hi Kevin, I will give it a try! Can you try on your end with helper = manager-core (the default of 2.29.2)? I've just tried a git push here and I was prompted to input my Azure credentials again. – Jonathan Dec 23 '20 at 17:41
  • Of course. I keep the system gitconfig file with the same settings. The gitconfig file in the answer is in the current user folder. Based on my test, the GIT credentials still exists after 24 hours. – Kevin Lu-MSFT Dec 24 '20 at 07:12
  • Kevin, can you test with the same setup I have (same gitconfig entries for the "credential" sections - you can find the ones I am using in the issue description)? I keep losing my saved credentials after ~24h and I am wondering if this is something GIT introduced (and hopefully can be adjusted) or something else is going on here. What I know so far is that a reboot is not causing the credentials to disappear, which is the expected behavior. – Jonathan Jan 03 '21 at 15:41
  • I have tested with the same gitconfig settings and the credentials hasn't been removed after 24 hours. If you manually add the credentials , will it be deleted after 24 hours? – Kevin Lu-MSFT Jan 04 '21 at 09:30
  • I'm afraid I won't be able to do that... I've used SSO to generate the credentials, so I am not sure what it inserted as "password" there. I tried with the PIN of my smart card (we use smart cards here) with no luck. Ideas? – Jonathan Jan 04 '21 at 18:31
  • You could use the PAT as the password. – Kevin Lu-MSFT Jan 05 '21 at 15:18
  • I will try and will let you know! – Jonathan Jan 08 '21 at 22:32

1 Answers1

1

I have checked my local git credentials(git version: git version 2.29.2.windows.3) and the credentials haven't disappeared for the time being.

You could try the following steps to check if the credentials can work as expected.

1.You can manually create a credential for Azure Devops Git on the local machine.

Windows Credential Manager -> Add a Generic Credential

enter image description here

Internet or network address format: git:https://dev.azure.com/organizationname

2.You can find the .gitconfig file content in the C:\Users\TargetUser. Then you could check if the credential is store mode.

[credential]
    helper = store

If not, you could run the following command to create it and check if the credentials still be deleted after 24 hours.

git config --global credential.helper store

3.I also tested the same steps on git version 2.28.0 and it can work fine too. You could try to install the previous version of git and try if it works.

Additional information: On my local machine, even if the PAT has expired, the git credential will not be deleted automatically.

On the other hand, you can also try to use SSH key authentication for a workaround.

You could refer to this doc for more detailed information.

Kevin Lu-MSFT
  • 20,786
  • 3
  • 19
  • 28