Permanently authenticating with Git repositories
In addition to SSH, Bitbucket Data Center and Server supports HTTP or HTTPS for pushing and pulling from managed Git repositories. However, Git does not cache the user's credentials by default, so you need to re-enter them each time you perform a clone, push, or pull.
This page describes two methods for permanently authenticating with Git repositories so that you can avoid typing your username and password each time you are pushing to or pulling from Bitbucket.
On this page
Using credential caching
You need Git 1.7.9 or above to use the HTTPS Credentials Caching feature.
On Windows you can use the application git-credential-winstore.
- Download the software.
- Run it.
- You will be prompted for credentials the first time you access a repository, and Windows will store your credentials for use in the future.
On Linux you can use the 'cache' authentication helper that is bundled with Git 1.7.9 and higher. From the Git documentation:
This command caches credentials in memory for use by future git programs. The stored credentials never touch the disk, and are forgotten after a configurable timeout. The cache is accessible over a Unix domain socket,
restricted to the current user by filesystem permissions.
Run the command below to enable credential caching. After enabling credential caching any time you enter your password it will be cached for 1 hour (3600 seconds):
git config --global credential.helper 'cache --timeout 3600'
Run the command below for an overview of all configuration options for the 'cache' authentication helper:
git help credential-cache
If you’re using macOS, Git comes with an "oxykeychain" mode. For more instructions, see credential storage.
Using the .netrc file
.netrc file is a mechanism that allows you to specify which credentials to use for which server. This method allows you to avoid entering a username and password every time you push to or pull from Git, but your Git password is stored in plain text.
- Git uses a utility called cURL under the covers, which respects the use of the .netrc file. Be aware that other applications that use cURL to make requests to servers defined in your
.netrcfile will also now be authenticated using these credentials. Also, this method of authentication is potentially unsuitable if you are accessing your Bitbucket instance via a proxy, as all cURL requests that target a path on that proxy server will be authenticated using your
- cURL will not match the machine name in your .netrc if it has a username in it, so make sure you edit your
.git/configfile in the root of your clone of the repository and remove the user and '@' part from any clone URL's (URL fields) that look like
https://firstname.lastname@example.org/...to make them look like
- Create a text file called
_netrcin your home directory (e.g.
c:\users\kannonboy\_netrc). cURL has problems resolving your home directory if it contains spaces in its path (e.g.
c:\Documents and Settings\kannonboy). However, you can update your
%HOME%environment variable to point to any directory, so create your
_netrcin a directory with no spaces in it (for example
c:\curl-auth\) then set your
%HOME%environment variable to point to the newly created directory.
Add credentials to the file for the server or servers you want to store credentials for, using the format described below:
machine stash1.mycompany.com login myusername password mypassword machine stash2.mycompany.com login myotherusername password myotherpassword
Linux or macOS
- Create a file called
.netrcin your home directory (
~/.netrc). Unfortunately, the syntax requires you to store your passwords in plain text - so make sure you modify the file permissions to make it readable only to you.
Add credentials to the file for the server or servers you want to store credentials for, using the format described in the 'Windows' section above. You may use either IP addresses or hostnames, and you do not need to specify a port number, even if you're running Bitbucket on a non-standard port.
- And that's it! Subsequent
git pushrequests will now be authenticated using the credentials specified in this file.
Was this helpful?Yes Provide feedback about this article