14

This is becoming even more important now with the new 2-factor authentication, as one has to create a new token each time a password is required on the terminal. Basically, I'm looking for an equvalent to the osxkeychain available in OS X that I could use on Linux desktops and servers:

git config --global credential.helper osxkeychain

I searched through the possible solutions, but so far I don't like any of them:

  • ssh instead of https - not recommended and links not easily accessible on GitHub
  • cache --timeout=3600 - it will expire eventually and reentering the password is a drag with the new 2FA
  • gnome-keyring - doesn't work on a headless server (at least not too elegantly - the ssh passphrase keyring is much nicer)
  • the encrypted .netrc file on my hard-drive method - poor man's manual keyring implementation?

Come on, there's got to be some proper terminal-based keychain for Linux that can be hooked to git's credential.helper!

Community
  • 1
  • 1
metakermit
  • 21,267
  • 15
  • 86
  • 95
  • 1
    You have a store `git config --global credential.helper store`, although the password will be stored on your hard disk drive in an unecrypted way. – Willem Van Onsem Sep 16 '13 at 22:52
  • Yeah, that's what I meant with [the .netrc method](http://stackoverflow.com/questions/5343068/is-there-a-way-to-skip-password-typing-when-using-https-github/18362082#18362082) - it is possible to encrypt it, but manually. – metakermit Sep 16 '13 at 23:13
  • What about kerberos authentication? http://blog.gegg.us/2012/12/the-perfect-gitolite-server-with-kerberos-authentication-and-more/ – Willem Van Onsem Sep 16 '13 at 23:15
  • Well, the same comment I gave bellow to VonC applies - I'm sure that it works, but I don't feel competent enough to be copying scripts around and manually writing passwords in files and encrypting them. If this was packaged to fit git's credential.helper interface by someone who really knows what he's doing and passed the necessary reviews to enter e.g. Debian's package repository, then I'd be delighted to use it. – metakermit Sep 17 '13 at 09:00
  • @kermit666 but I described *all* the steps in http://stackoverflow.com/a/18362082/6309 ;) – VonC Sep 17 '13 at 09:08
  • Not a single answer to the [linked SO question](https://stackoverflow.com/questions/11200237/how-do-i-get-git-to-default-to-ssh-and-not-https-for-new-repositories) where @metakermit says "ssh instead of https - not recommended" says that ssh isn't recommended. – kapad Aug 11 '18 at 07:45
  • Does this answer your question? [Is there a way to cache GitHub credentials for pushing commits?](https://stackoverflow.com/questions/5343068/is-there-a-way-to-cache-github-credentials-for-pushing-commits) – Liam Mar 22 '21 at 13:08

3 Answers3

6

I would still recommend the method I describe in "Is there a way to skip password typing when using https://github.com"

Encrypting your .netrc allows you to store multiple credentials (to GitHub, and BitBicket, and ...) in one file, and have it used through the git credential helper netrc (git1.8.3+).

And it is compatible with the Github two-factor authentication, as I detail in "Configure Git clients, like GitHub for Windows, to not ask for authentication".

It works on Windows (and Linux or Mac).
And you can limit the number of minutes/hours during which gpg won't ask you again for the private key passphrase.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Yes, that does seem like a good option, but I don't like the notion of manual steps when it comes to dealing with security. Do you think it would be hard to package it into something more black-boxy like osxkeychain or ssh-agent (is that what ssh's passphrase manager is called?)? – metakermit Sep 17 '13 at 08:52
  • @kermit666 which manual step? Beside the initial encryption of the `.netrc` file, the rest is entirely automatic (except, obviously, the step where you enter your gpg key passphrase to the `gpg-agent`). – VonC Sep 17 '13 at 09:07
  • Well, from what I understand, I have to copy [the netrc script](https://raw.github.com/git/git/master/contrib/credential/netrc/git-credential-netrc) to '/usr/local/bin' and make it executable, create the file with the passphrase, set its permissions, encrypt it. In contrast, when using osxkeychain or ssh-agent, I don't have to install anything (part of the OS), they ask me to enter a passphrase into a prompt (not a file) the first time (when first adding something to the keychain / first creating the RSA keypair) and they take care of everything else - only prompt me to unlock it. – metakermit Sep 17 '13 at 09:31
  • @kermit666 I understand, but it does work :) And you can copy the `netrc` script in any folder present in your `PATH`. Make sure you have gpg2 installed, not just gpg. – VonC Sep 17 '13 at 09:33
1

The 2022 answer would be to use the Microsft cross-platform GCM (Git Credential Manager)

See "Git Credential Manager: authentication for everyone" (Ensuring secure access to your source code is more important than ever. Git Credential Manager helps make that easy) from Matthew John Cheetham (Senior Software Engineer at @github).

Hello, Linux!

https://github.blog/wp-content/uploads/2022/04/4-gcm-linux.png?resize=1024%2C418?w=1024

In the quest to become a universal solution for Git authentication, we’ve worked hard on getting GCM to work well on various Linux distributions, with a primary focus on Debian-based distributions.

Today we have Debian packages available to download from our GitHub releases page, as well as tarballs for other distributions (64-bit Intel only). Being built on the .NET platform means there should be a reduced effort to build and run anywhere the .NET runtime runs. Over time, we hope to expand our support matrix of distributions and CPU architectures (by adding ARM64 support, for example).

Due to the broad and varied nature of Linux distributions, it’s important that GCM offers many different credential storage options. In addition to GPG encrypted files, we added support for the Secret Service API via libsecret (also see the GNOME Keyring), which provides a similar experience to what we provide today in GCM on Windows and macOS.

See Linux installation, and additional configuration.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
-9

This method is not recommend, but still if you are in rush and nothing else is working for you, Simply add a new remote as

git remote -rm origin 

git remote add origin https://username:mypassword@github.com/path/to/repo.git

that's it now you don't need to enter password again and again

Note: This method doesn't work with two step authorization accounts

Tarun Gupta
  • 6,305
  • 2
  • 42
  • 39
  • 5
    So you are advocating storing your password in plain text for anyone to see if you chose to do a "git remote -v" while some developers are sitting around? – Thomas Beauvais Jul 30 '14 at 09:32
  • I think you would never go in to that situation. else if you have such scenario you can use this "git config --global credential.helper store". Above can be helpful when you are in rush to clone work and push pull to some repo. – Tarun Gupta Aug 01 '14 at 05:00
  • This is okay as long if you generate a custom application credential in GitHub. Passwords don't work over two-factor authentication anyway. – Andrew Mao Sep 21 '14 at 19:10
  • 2
    Please do not downvote the answer, as this is one of the way given via git only, and even I m not recommending it. Just helping people to know another method which might be helpful in some cases – Tarun Gupta Jun 18 '17 at 02:41
  • 2
    Plaintext passwords should never be stored on a system. You should use an [PAT - Personal Access Token](https://help.github.com/en/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line), then the URL would be https://username:PERSONAL_ACCESS_TOKEN@github.com/user/project.git. In that case you can revoke the PAT, if it was leaked. And the password is safe! – KargWare Apr 09 '20 at 13:29