What's the best encrypted git credential helper for Linux?

Question

I've been looking for a good encrypted git credential helper for Linux (something that can store passwords in an encrypted way, and retrieve them later, conforming to the git-credential protocol), and I'm really surprised that not much seems to be turning up.

In all of the git docs and related git-credential documentation I've seen, they don't even mention the existence of such a thing. It always mentions osxkeychain for Mac, but then if you're running Linux it just redirects you to the doc that explains how to use "cache" as a helper. Some of the references mention Microsoft's git credential manager to use for Windows. But nothing for Linux.

Using cache seems like a semi-okay solution if you use actual passwords. Not terrible, but far from ideal. But if you're using Personal Access Tokens (which you have to use if you want to maintain 2 Factor security on the account for your repo), then that's a no-go. Having to type in one of those randomly-generated PAT's once in a while, no matter how infrequent, is a really bad idea. You can't realistically memorize them, and storing them somewhere in plain text is a security compromise. (Also, what if you want to automate some git operations? Not going to work.)

So--what is the solution here? If it exists for both Windows and Mac, I'm sure there is at least one good option for Linux, probably many. I've heard you can do it with Gnome, for instance. But if you don't have Gnome, what should you do? I've heard that Microsoft's manager for Windows may run under Linux, but haven't tried it yet. Is that the only option out there? Is there an open source option?

Halie

Answer 1

This is what we have in git sources: https://github.com/git/git/tree/master/contrib/credential

So you can use gnome-keyring (deprecated), libsecret or gpg-encrypted .netrc.

libsecret could be used with any Linux distribution without GNOME, I believe.

git config --global credential.helper /usr/share/doc/git/contrib/credential/libsecret/git-credential-libsecret

See https://mcmap.net/q/13474/-error-when-using-git-credential-helper-with-gnome-keyring-as-sudo.

This is how to use gpg-encrypted .netrc: https://mcmap.net/q/13187/-is-there-a-way-to-cache-https-credentials-for-pushing-commits.

---

Reminder: libgnome-keyring is specific to GNOME and is:

• deprecated since January 2014
• completely removed with Git 2.41 (Q2 2023)

Cordalia

Thanks! Both of those look like good solutions--time to upgrade my git I guess. – Halie

Can't you also leave out the path and just do git config --global credential.helper libsecret? Works fine for me – Casady

If you notice the end of the command isn't libsecret it is git-credential-libsecret and since it isn't under /usr/local/bin or /usr/bin it might not be in the path for git to find it with just libsecret. I've tried with just libsecret on a non-standard system and it didn't work, but hopefully it does for most people. – Hadwin

On debian 10 buster I actually installed package gnome-keyring package to avoid the ``` ** (process:12939): CRITICAL **: 12:15:04.448: lookup failed: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets was not provided by any .service files ``` error. On buster you also have to compile git-credential-libsecret. – Gaffrigged

On Manjaro/Arch in 2022 the path is simply /usr/lib/git-core/git-credential-libsecret (otherwise, you may find it by running locate -b git-credential-libsecret) – Eritrea

On fedora and rhel-like systems, the path is /usr/libexec/git-core/git-credential-libsecret. It is provided by the package git-credential-libsecret – Calamint

Answer 2

If you already use a password manager like 1Password or Lastpass or pass or gopass you can probably use that for managing your git credentials as long as you are only using it on your local system or one that you trust.

I did a quick search and found a few git-credential-APPNAME helpers for each of the above (gopass should be compatible with the pass implementation).

Hadwin

The reason I asked was to use it on a remote machine which other people also have accounts on and I do not trust. I never did get any of the credential helpers to work, but I solved the problem I wanted to solve with ssh forwarding. Instead of checking out via https:// I just always checkout with ssh:// now, and as long as forwarding is set up, it can verify through my ssh agent that I have access to my github account. – Halie

With pass or gopass you could forward a key similar to what you do with SSH and only decrypt secrets when the key is present and unlocked. One thing to keep in mind when forwarding your SSH agent is to add a config that limits how it can be reused on the remote host. – Hadwin

Oh, so you can add something to the ssh config to say "only allow this key to be forwarded for authentication to github.com and no other host"? Thanks, that's a great idea! – Halie

@Halie I'm trying to solve the same problem now and I'm sure many people have wondered and will wonder the same thing as you. Could you write up the method you used with the relevant code for ssh forwarding and then interfacing with Git? (I'm happy to create a question around this if that'd help.) I think it'd be really useful for alot of people – Ovary

@Mobeus Zoom If you're already used to using ssh-agent locally (so that you can password protect your ssh key while you're not logged in, but don't have to re-type it every time you ssh to somewhere else) then it's not hard to get it working on a foreign host with git: the important step is to add the line ForwardAgent yes to ~/.ssh/config. You can test that it's working on remote host with ssh-add -l, then either re-run git clone with an SSH style url, or use git remote add instead. Getting ssh-agent setup properly is a longer subject, but many good answers are out there. – Halie

Answer 3

Try git-credential-oauth, included in many Linux distributions including Fedora, Debian and Ubuntu.

No more passwords! No more personal access tokens! No more SSH keys!

A Git credential helper that securely authenticates to GitHub, GitLab, BitBucket and other forges using OAuth.

The first time you push, the helper will open a browser window to authenticate. Subsequent pushes within storage lifetime require no interaction.

This is compatible with any storage helper you choose, such as git-credential-cache or git-credential-libsecret.

Pier