How to store your github https password on Linux in a terminal keychain?

Question

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!

Shofar

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. – Incubus

Yeah, that's what I meant with the .netrc method - it is possible to encrypt it, but manually. – Shofar

What about kerberos authentication? blog.gegg.us/2012/12/… – Incubus

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. – Shofar

@kermit666 but I described all the steps in https://mcmap.net/q/13187/-is-there-a-way-to-cache-https-credentials-for-pushing-commits ;) – Comment

Not a single answer to the linked SO question where @Shofar says "ssh instead of https - not recommended" says that ssh isn't recommended. – Trimaran

Does this answer your question? Is there a way to cache GitHub credentials for pushing commits? – Series

Answer 1

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.

Comment

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?)? – Shofar

@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). – Comment

Well, from what I understand, I have to copy the netrc script 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. – Shofar

@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. – Comment

Answer 2

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!

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.

Comment

Answer 3

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:[email protected]/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

Guarneri

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? – Defecate

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. – Guarneri

This is okay as long if you generate a custom application credential in GitHub. Passwords don't work over two-factor authentication anyway. – Phox

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 – Guarneri

Plaintext passwords should never be stored on a system. You should use an PAT - Personal Access Token, then the URL would be username:[email protected]/user/project.git. In that case you can revoke the PAT, if it was leaked. And the password is safe! – Preclude