Git credentials store windows

Setup and Config

Getting and Creating Projects

Basic Snapshotting

Branching and Merging

Sharing and Updating Projects

Inspection and Comparison

Patching

Debugging

Email

External Systems

Server Admin

Guides

Administration

Plumbing Commands

Check your version of git by running

git-credential-store — Helper to store credentials on disk

SYNOPSIS

DESCRIPTION

Using this helper will store your passwords unencrypted on disk, protected only by filesystem permissions. If this is not an acceptable security tradeoff, try git-credential-cache[1], or find a helper that integrates with secure storage provided by your operating system.

This command stores credentials indefinitely on disk for use by future Git programs.

You probably don’t want to invoke this command directly; it is meant to be used as a credential helper by other parts of git. See gitcredentials[7] or EXAMPLES below.

OPTIONS

to lookup and store credentials. The file will have its filesystem permissions set to prevent other users on the system from reading it, but will not be encrypted or otherwise protected. If not specified, credentials will be searched for from

/.git-credentials and $XDG_CONFIG_HOME/git/credentials , and credentials will be written to

/.git-credentials if it exists, or $XDG_CONFIG_HOME/git/credentials if it exists and the former does not. See also FILES.

FILES

If not set explicitly with —file , there are two files where git-credential-store will search for credentials in order of precedence:

User-specific credentials file.

Second user-specific credentials file. If $XDG_CONFIG_HOME is not set or empty, $HOME/.config/git/credentials will be used. Any credentials stored in this file will not be used if

/.git-credentials has a matching credential as well. It is a good idea not to create this file if you sometimes use older versions of Git that do not support it.

For credential lookups, the files are read in the order given above, with the first matching credential found taking precedence over credentials found in files further down the list.

Credential storage will by default write to the first existing file in the list. If none of these files exist,

/.git-credentials will be created and written to.

When erasing credentials, matching credentials will be erased from all files.

EXAMPLES

The point of this helper is to reduce the number of times you must type your username or password. For example:

STORAGE FORMAT

The .git-credentials file is stored in plaintext. Each credential is stored on its own line as a URL like:

No other kinds of lines (e.g. empty lines or comment lines) are allowed in the file, even though some may be silently ignored. Do not view or edit the file with editors.

When Git needs authentication for a particular URL context, credential-store will consider that context a pattern to match against each entry in the credentials file. If the protocol, hostname, and username (if we already have one) match, then the password is returned to Git. See the discussion of configuration in gitcredentials[7] for more information.

7.14 Git Tools — Credential Storage

Credential Storage

If you use the SSH transport for connecting to remotes, it’s possible for you to have a key without a passphrase, which allows you to securely transfer data without typing in your username and password. However, this isn’t possible with the HTTP protocols – every connection needs a username and password. This gets even harder for systems with two-factor authentication, where the token you use for a password is randomly generated and unpronounceable.

Fortunately, Git has a credentials system that can help with this. Git has a few options provided in the box:

The default is not to cache at all. Every connection will prompt you for your username and password.

The “cache” mode keeps credentials in memory for a certain period of time. None of the passwords are ever stored on disk, and they are purged from the cache after 15 minutes.

The “store” mode saves the credentials to a plain-text file on disk, and they never expire. This means that until you change your password for the Git host, you won’t ever have to type in your credentials again. The downside of this approach is that your passwords are stored in cleartext in a plain file in your home directory.

If you’re using a Mac, Git comes with an “osxkeychain” mode, which caches credentials in the secure keychain that’s attached to your system account. This method stores the credentials on disk, and they never expire, but they’re encrypted with the same system that stores HTTPS certificates and Safari auto-fills.

If you’re using Windows, you can install a helper called “Git Credential Manager for Windows.” This is similar to the “osxkeychain” helper described above, but uses the Windows Credential Store to control sensitive information. It can be found at https://github.com/Microsoft/Git-Credential-Manager-for-Windows.

You can choose one of these methods by setting a Git configuration value:

Some of these helpers have options. The “store” helper can take a —file

argument, which customizes where the plain-text file is saved (the default is

/.git-credentials ). The “cache” helper accepts the —timeout option, which changes the amount of time its daemon is kept running (the default is “900”, or 15 minutes). Here’s an example of how you’d configure the “store” helper with a custom file name:

Git even allows you to configure several helpers. When looking for credentials for a particular host, Git will query them in order, and stop after the first answer is provided. When saving credentials, Git will send the username and password to all of the helpers in the list, and they can choose what to do with them. Here’s what a .gitconfig would look like if you had a credentials file on a thumb drive, but wanted to use the in-memory cache to save some typing if the drive isn’t plugged in:

Under the Hood

How does this all work? Git’s root command for the credential-helper system is git credential , which takes a command as an argument, and then more input through stdin.

This might be easier to understand with an example. Let’s say that a credential helper has been configured, and the helper has stored credentials for mygithost . Here’s a session that uses the “fill” command, which is invoked when Git is trying to find credentials for a host:

This is the command line that initiates the interaction.

Git-credential is then waiting for input on stdin. We provide it with the things we know: the protocol and hostname.

A blank line indicates that the input is complete, and the credential system should answer with what it knows.

Git-credential then takes over, and writes to stdout with the bits of information it found.

If credentials are not found, Git asks the user for the username and password, and provides them back to the invoking stdout (here they’re attached to the same console).

The credential system is actually invoking a program that’s separate from Git itself; which one and how depends on the credential.helper configuration value. There are several forms it can take:

Runs git-credential-foo -a —opt=bcd

Runs /absolute/path/foo -xyz

Code after ! evaluated in shell

So the helpers described above are actually named git-credential-cache , git-credential-store , and so on, and we can configure them to take command-line arguments. The general form for this is “git-credential-foo [args] .” The stdin/stdout protocol is the same as git-credential, but they use a slightly different set of actions:

get is a request for a username/password pair.

store is a request to save a set of credentials in this helper’s memory.

erase purge the credentials for the given properties from this helper’s memory.

For the store and erase actions, no response is required (Git ignores it anyway). For the get action, however, Git is very interested in what the helper has to say. If the helper doesn’t know anything useful, it can simply exit with no output, but if it does know, it should augment the provided information with the information it has stored. The output is treated like a series of assignment statements; anything provided will replace what Git already knows.

Here’s the same example from above, but skipping git-credential and going straight for git-credential-store:

Here we tell git-credential-store to save some credentials: the username “bob” and the password “s3cre7” are to be used when https://mygithost is accessed.

Now we’ll retrieve those credentials. We provide the parts of the connection we already know ( https://mygithost ), and an empty line.

git-credential-store replies with the username and password we stored above.

/git.store file looks like:

It’s just a series of lines, each of which contains a credential-decorated URL. The osxkeychain and wincred helpers use the native format of their backing stores, while cache uses its own in-memory format (which no other process can read).

A Custom Credential Cache

Given that git-credential-store and friends are separate programs from Git, it’s not much of a leap to realize that any program can be a Git credential helper. The helpers provided by Git cover many common use cases, but not all. For example, let’s say your team has some credentials that are shared with the entire team, perhaps for deployment. These are stored in a shared directory, but you don’t want to copy them to your own credential store, because they change often. None of the existing helpers cover this case; let’s see what it would take to write our own. There are several key features this program needs to have:

The only action we need to pay attention to is get ; store and erase are write operations, so we’ll just exit cleanly when they’re received.

The file format of the shared-credential file is the same as that used by git-credential-store .

The location of that file is fairly standard, but we should allow the user to pass a custom path just in case.

Once again, we’ll write this extension in Ruby, but any language will work so long as Git can execute the finished product. Here’s the full source code of our new credential helper:

Here we parse the command-line options, allowing the user to specify the input file. The default is

This program only responds if the action is get and the backing-store file exists.

This loop reads from stdin until the first blank line is reached. The inputs are stored in the known hash for later reference.

This loop reads the contents of the storage file, looking for matches. If the protocol and host from known match this line, the program prints the results to stdout and exits.

We’ll save our helper as git-credential-read-only , put it somewhere in our PATH and mark it executable. Here’s what an interactive session looks like:

Since its name starts with “git-”, we can use the simple syntax for the configuration value:

As you can see, extending this system is pretty straightforward, and can solve some common problems for you and your team.

How to use Git credential store on WSL (Ubuntu on Windows)?

I’ve tried following these instructions: https://stackoverflow.com/a/40312117/21728 which basically do this:

But when I do any network operation, I get this error:

That’s logical I guess as there is indeed no X11 display.

How to make Git credentials caching work on Ubuntu on Windows (WSL)?

7 Answers 7

If you installed Git for Windows there is a windows integrated credential manager installed on your system.

You can run windows executables from WSL as found here.

To use it you can run the following command (assuming that your git for windows is installed on C:\Program Files\Git)

I’ve created a script that does this for you. I use it with my Chef orchestration.

Locate or install git-credential-manager.exe

1. Open cmd.exe and call where git-credential-manager.exe
   • If it returns a path, GREAT. Move on to converting the path.
   • If not.
2. In cmd.exe call where git.exe
   • If it does not return a path, the next step is to install the Credential Manager alone
   • If it does return a path, it will be something like:
   • C:\Program Files\Git\cmd\git.exe
   • Let’s drop the everything after the next to last slash and change it like so:
   • C:\Program Files\Git\mingw64\libexec\git-core\git-credential-manager.exe
   • If that exists, GREAT. Move on to converting the path.
   • Otherwise.
3. Install Credential Manager from Microsoft’s git repo, and then use where again to get the path.

Convert the path from DOS to Linux

1. Replace the C:\ with /mnt/c/
2. Flip the slashes from \ to /
3. Escape spaces (and parenthesis if there are any) with double backslashes \\

• «C:\Program Files\Git\mingw64\libexec\git-core\git-credential-manager.exe» becomes.
• «/mnt/c/Program\\ Files/Git/mingw64/libexec/git-core/git-credential-manager.exe»

My script above has a function for doing just that

But, as @12345ieee has since commented, a wslpath utility has been added to WSL build 17046. It’s worth checking out, but I don’t have access to Windows at this time to verify. (Note that even though a usage statement is given in the release notes in my link, it seems that the command doesn’t currently include a usage statement, -h, etc.)

Git credentials store windows

Git Credential Manager for Windows

NOTICE: This project is no longer being maintained. ⚠️

Git Credential Manager for Windows is no longer being maintained. The cross-platform Git Credential Manager Core (GCM Core) is the official replacement.

GCM Core is included as an optional component of Git for Windows 2.28 and will be made the default credential helper as of Git for Windows 2.29. GCM Core can also be manually installed from this page.

NOTICE: Experiencing GitHub push/fetch problems?

GitHub will disable password-based authentication on APIs Git Credential Manager for Windows uses to create tokens. As a result, GCM for Windows will no longer be able to create new access tokens for GitHub.

Git Credential Manager Core (GCM Core) supports OAuth-based authentication with GitHub and is the replacement for GCM for Windows.

Please update to Git for Windows 2.28 and select «Git Credential Manager Core» from the installer when asked to «select a credential helper», or manually install GCM Core from here.

As of 22 Feb 2018, GitHub has disabled support for weak encryption which means many users will suddenly find themselves unable to authenticate using a Git for Windows which (impacts versions older than v2.16.0). DO NOT PANIC, there’s a fix. Update Git for Windows to the latest (or at least v2.16.0).

The most common error users see looks like:

If, after updating Git for Windows, you are still having problems authenticating with GitHub, please read this Developer Community topic which contains additional remedial actions you can take to resolve the problem.

If you are experiencing issue when using Visual Studio, please read Unable to connect to GitHub with Visual Studio.

The Git Credential Manager for Windows (GCM) provides secure Git credential storage for Windows. It’s the successor to the Windows Credential Store for Git (git-credential-winstore), which is no longer maintained. Compared to Git’s built-in credential storage for Windows (wincred), which provides single-factor authentication support working on any HTTP enabled Git repository, GCM provides multi-factor authentication support for Azure DevOps, Team Foundation Server, GitHub, and Bitbucket.

This project includes:

• Secure password storage in the Windows Credential Store.
• Multi-factor authentication support for Azure DevOps.
• Two-factor authentication support for GitHub.
• Two-factor authentication support for Bitbucket.
• Personal Access Token generation and usage support for Azure DevOps, GitHub, and Bitbucket.
• Non-interactive mode support for Azure DevOps backed by Azure Directory.
• NTLM/Kerberos authentication for Team Foundation Server (see notes).
• Optional settings for build agent optimization.

This is a community project so feel free to contribute ideas, submit bugs, fix bugs, or code new features. For detailed information on how the GCM works go to the wiki.

Download and Install

To use the GCM, you can download the latest installer. To install, double-click GCMW-.exe and follow the instructions presented.

When prompted to select your terminal emulator for Git Bash you should choose the Windows’ default console window, or make sure GCM is configured to use modal dialogs. GCM cannot prompt you for credentials, at the console, in a MinTTY setup.

Note for users with special installation needs, you can still extract the gcm-.zip file and run install.cmd from an administrator command prompt. This allows specification of the installation options explained below.

Installation in an MSYS2 Environment

To use the GCM along with git installed with pacman in an MSYS2 environment, simply download a release zip and extract the contents directly into C:\msys64\usr\lib\git-core (assuming your MSYS2 environment is installed in C:\msys64 ). Then run:

You don’t. It magically works when credentials are needed. For example, when pushing to Azure DevOps, it automatically opens a window and initializes an oauth2 flow to get your token.

Build and Install from Sources

To build and install the GCM yourself, clone the sources, open the solution file in Visual Studio, and build the solution. All necessary components will be copied from the build output locations into a .\Deploy folder at the root of the solution. From an elevated command prompt in the .\Deploy folder issue the following command git-credential-manager install . Additional information about development and debugging are available in our documents area.

Various options are available for uniquely configured systems, like automated build systems. For systems with a non-standard placement of Git use the —path parameter to supply where Git is located and thus where the GCM should be deployed to. For systems looking to avoid checking for the Microsoft .NET Framework and other similar prerequisites use the —force option. For systems looking for silent installation without any prompts, use the —passive option.

There are many ways to contribute.

• Submit bugs and help us verify fixes as they are checked in.
• Review code changes.
• Contribute bug fixes and features.

For code contributions, you will need to complete a Contributor License Agreement (CLA). Briefly, this agreement testifies that you grant us permission to use the submitted change according to the terms of the project’s license, and that the work being submitted is under the appropriate copyright.

Please submit a Contributor License Agreement (CLA) before submitting a pull request. You may visit https://cla.microsoft.com to sign digitally. Alternatively, download the agreement Microsoft Contribution License Agreement.pdf, sign, scan, and email it back to cla@microsoft.com. Be sure to include your GitHub user name along with the agreement. Once we have received the signed CLA, we’ll review the request.

Code of Conduct

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

This project uses the MIT License.

About

Secure Git credential storage for Windows with support for Visual Studio Team Services, GitHub, and Bitbucket multi-factor authentication.