Git http - securely remember credentials

Question

Is there a way to securely let git remember my credentials when connecting to remote repositories over HTTP(S)?

I've tried the core.askpass approach detailed in git-config to let an external script supply my credentials. Although it works great the username and password is still stored in plain text in the small shell script.

Solution 1

git invokes cURL when running over HTTP. You can store secure credentials by setting up a .netrc file in your user's home directory, and making it private to the user (0600 in Linux).

The contents of the file provide the username and password per remote domain.

machine myRemoteServer
login myUserName
password s3cret

See https://stackoverflow.com/questions/3947530/git-push-fatal-failed/7177690#7177690 for full server side configuration, which can easily include calls to your ldap server.

Solution 2

Since (I think) git version 1.7.8, from 2 December 2011¹⁾, git supports so called credentials helpers.

See gitcredentials(7) manpage for details
^{(This manpage also decribes where core.askpass fits into this).}

The default git installation includes two helpers:

• cache: See git-credential-cache(1) for details.

  Cache credentials in memory for a short period of time. The stored credentials never touch the disk, and are forgotten after a configurable timeout. Note that it is Unix-only solution, as it uses socket to communicate with daemon.

• store: See git-credential-store(1) for details.

  Store credentials indefinitely on disk. 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. The same security as .netrc solution in Eddie response

---

There are some third-party credential helpers for storing username and password in KDEWallet (KDE), in GNOME Keyring, in Windows Credential Store (this is now integrated in Git for Windows), in MacOS X Keychain, etc.

---

Footnotes:

¹⁾ The Set Up Git GitHub Help page mentions that

You need git 1.7.10 or newer to use the credential helper

Solution 3

Since git 1.8.3 (May, 2013), you now can specify an encrypted .netrc for git to use:

A new read-only credential helper (in contrib/credential/netrc/) to interact with the .netrc/.authinfo files has been added.

That script would allow you to use gpg-encrypted netrc files, avoiding the issue of having your credentials stored in a plain text file.

-f|--file AUTHFILE
specify netrc-style files.  

Files with the .gpg extension will be decrypted by GPG before parsing.
Multiple -f arguments are OK. They are processed in order, and the first matching entry found is returned via the credential helper protocol (see below).

When no -f option is given, .authinfo.gpg, .netrc.gpg, .authinfo, and .netrc files in your home directory are used in this order.

To enable this credential helper:

git config credential.helper '$shortname -f AUTHFILE1 -f AUTHFILE2'

(Note that Git will prepend "git-credential-" to the helper name and look for it in the path.)

---

See a complete step-by-step example at:
"Is there a way to skip password typing when using https://github.com".

Solution 4

Secure option is to use regular SSH with public/private key pair.

Solution 5

This might work for you... http://samuel.kadolph.com/2011/03/store-your-git-https-passwords-in-your-os-x-keychain/

View more solutions

Comments

[Eddie]

This is more secure then typing passwords in the command because command history files are world readable, whereas .netrc should explicity be hidden from anyone except the owning user.. Example on linux/cygwin of the bash_history file's permissions (-rw-r--r-- 1 myName Domain Users 8955 Aug 24 12:53 .bash_history)

[Ryan B. Lynch]

that's also true because it prevents the password string from being world-visible in the output of 'ps -ax' while Git commands are running.

[Ryan B. Lynch]

@John, I'm downvoting: Proper, authenticated HTTPS transport is just as secure as SSH, between the Git client and server. In larger organizations, a centralized, single-account provisioning/revoking of user access is a very common constraint. AFAIK, OpenSSH can only handle user pubkeys in local files, NOT via directory lookups (e.g., LDAP).

[Johan Sjöberg]

Also see Git - How to use .netrc file on windows to save user and password

[Anonigan]

@RyanB.Lynch: FYI there is OpenSSH-LPK to store public keys in LDAP, but it is patched OpenSSH code.google.com/p/openssh-lpk

[MKroehnert]

The credentials cache method works without problems with Git 1.7.9.5 under Ubuntu 12.04. Thanks for the pointers.

[broc.seib]

Thanks -- this did the trick for me: git config credential.helper store

[Alex]

If you do not provide a password on the command line git will prompt you for one. This means it is not visible in bash history. If you store it in .netrc, then anyone with physical access or root access to the machine can read your password as it is stored in plain text. However you will have to type it every time which is really inconvenient.

[Jesse Glick]

Or in one line: machine github.com login jqhacker password s3cret

[Jesse Glick]

@eddie my suggestion above was an alternate .netrc syntax, not a shell command.

[Eddie]

I see that now @jesseglick, I think I was in a haze of unrelated questions when I posted.

[YakovL]

Let me note that for Windows users the situation is different: stackoverflow.com/q/11693074/…

[kkm]

8 years later: There is an option AuthorizedKeysCommand in sshd_config which, if provided, specifies a program or script which is run to fetch user's public keys. I do not know the minimum version of OpenSSH that supports it, but it has been around for a few years. This is, for one, how ssh authentication is implemented in Google Cloud VMs to allow login into a fresh VM (public keys are either stored in VM's or project configuration, or, in another mode, added to the user's Google account, for a true SSO).