How to fix git error "Failed to enumerate credentials. [0x520]"

Question

I'm using git over ssh on a remote machine that is running Windows 10. When I try to do a git pull, I get the error message in the title after entering my credentials.

Answer 1

Fixed by installing the latest version of git credential manager on chocolatey (not sure if this is necessary) and switching my git credential store to dpapi.

See https://github.com/GitCredentialManager/git-credential-manager/blob/main/docs/credstores.md#dpapi-protected-files for instructions on how to do so.

Answer 2

This could be illustrated by GitCredentialManager/git-credential-manager issue 325

The error you're seeing is related to the way that Windows handles "logon sessions" and "credential sets".

GCM Core uses the Windows Credential Manager (wincred.h) to store credentials safely on Windows.
We interact with wincred via the Windows APIs: CredRead, CredWrite, CredDelete, and CredEnumerate.

The error being returned in your case here is ERROR_NO_SUCH_LOGON_SESSION (0x520) which means:

The logon session does not exist or there is no credential set associated with this logon session.
Network logon sessions do not have an associated credential set.

The key part here is in bold.

When you connect via SSH, the sshd daemon/Windows service is running as the NT AUTHORITY\NETWORK SERVICE account (most likely/by default), which creates network logon sessions when an SSH client connects.

From some searching online, one workaround posted is to change the account that sshd runs as to be your real user, which would then have an associated credential set. Your milage may vary here depending on setup.

If you try to use the built-in cmdkey command for interacting credentials stores in the Windows Credential Manager, you'll see similar errors or messages like "saved for this login only".

Upgrading to the latest version of GCM comes with:

With the latest GCM Core release (v2.0.567) there is support on Windows to use a different credential store other than the Windows Credential Manager that shouldn't have the same remote-session limitations.

You can read more about the different options here: https://aka.ms/gcmcore-credstores

The specific store that may help this SSH scenario is the DPAPI-protected file store.
Credentials are protected using Windows DPAPI encryption (based on your current user account) and are written to files on disk (configurable; defaults to %USERPROFILE%\.gcm\dpapi_store).