I'm using git with GnuPG signing. Each time I want to sign a commit I have to provide my GnuPG key password.
Is it possible to make git take advantage of some system-wide keyring, like gnome-keyring? I can't seem to find any documentation on that, or even any thread on this in the web. Perhaps there is some solution I'm not aware of, that is not popular enough to be easy to google.
There are probably some GUI tools that can do that for me, but I'm not interested in those, I mostly use git from console, sometimes from IntelliJ-based IDEs, which just invoke the system git binary. Having a system-side solution will allow me to use git config --global commit.gpgsign true with these IDEs (and cli).
Copied from https://superuser.com/questions/624343/keep-gnupg-credentials-cached-for-entire-user-session
Up to GnuPG 2
The user configuration (in ~/.gnupg/gpg-agent.conf) can only define
the default and maximum caching duration; it can't be disabled.
The default-cache-ttl option sets the timeout (in seconds) after the
last GnuPG activity (so it resets if you use it), the
maximum-cache-ttl option set the timespan (in seconds) it caches
after entering your password. The default value is 7200 (2 hours) for
both.
Set it to a year or so – say, 34560000 seconds (400 days) – and you
should be fine:
default-cache-ttl 34560000
maximum-cache-ttl 34560000
But for this change to take effect, you need to end the session by
restarting gpg-agent.
If you want to limit to your session length, you'd need to kill the
daemon at logout. This is very different between operating systems, so
I'm referring to another question/answer containing hints for
different
systems.
You could also restart the gpg-agent during login, but this does not
limit caching time to the session length, but logins of a user. Decide
yourself if this is a problem in your case.
GnuPG 2.1 and above
In GnuPG 2.1 and above, the maximum-cache-ttl option was renamed to
max-cache-ttl without further changes.
I see you use Fedora, in version 29, all I had to do was:
git config --global gpg.program gpg2
And it uses the Gnome Keychain (seahorse).
Related
I am a new programmer, and also still a "noob" using Debian based distributions and Linux in general. Every time I push to my GitHub repository as u know, I have to write username and password which is my GitHub token, I have the token stored in a file and I have to enter the file copy the token and use it, and it's a bit annoying, I know it's possible to store commands in variables to make shell use faster, is there some sort of way to do the same with my token? or which would be a good practice to do so?
Thanks in advance for your time.
You can cache your username/password with this command:
git config --global credential.helper 'cache --timeout=secs'
where secs (seconds) defaults to 900 (15 minutes).
I would suggest using SSH keys which you can find more information about here. When authenticating using SSH keys you don't have to type in your password manually.
A few things that would change would be that you should select the SSH option instead when you're going to clone your repository.
I believe the following command can change this configuration for repos that you've already cloned using HTTPS:
git remote set-url origin git#github.com:<username>/<repository-name>
I have been using gpg for encryption for a while. Someone suggested that I should use gpg2 instead. When I went to use gpg2, I could do almost nothing; it would complain that access to private keys was required, but I could not seem to get it to use the private keys without gpg-agent running.
It turns out that I intentionally disabled gpg-agent (by using chmod -x /usr/bin/gpg-agent); this caused gpg2 to have very limited functionality and complain to stderr.
The reasons I disabled gpg-agent was following a chain of events.
First, I would SSH into a remote machine and "an agent" would open a popup asking for me to unlock my SSH keys. I did not like this because:
A pop-up on my screen interrupts my workflow
A pop-up on my screen is unlikely to be noticed, so it would appear instead that the connection is stalling instead of querying to unlock an encryption key
The agent appeared to cache my password when I absolutely do not want my password cached (much like sudo's annoying use of password caching, I can disable that in its config); I will always want to enter the passphrase for my encryption keys every time they are used for whatever program is using them.
The pop-up appeared to be owned by a separate process, while I want the specific process using the key to query for the passphrase (even if it's a library that does the actual querying); since I spend most of my activities using command-line tools, that means a GUI application isn't ideal because not everything I do will have access to X11
Automatically starting a separate process in the background removes the concept of "one command, one process", especially if that backgrounded process then lingers after the original command has exited
It turned out to be GNOME's key agent and that I could not uninstall the agent without uninstalling GNOME. So I simply disabled it by chmod -x /usr/bin/gnome-keyring*. I then found that SSH would fall back to another agent so I disabled that too using the same method chmod -x /usr/bin/ssh-agent*
When I started using gpg, I found it had a similar agent, the same one I am asking about. I disabled it immediately for the same reasons; I want software to always ask me for passphrases in order to use a private key. I do not want the passphrase to be cached for any reason whatsoever.
So with gpg2 appearing to require gpg-agent, I would like to ask:
Am I being overly paranoid about the use of passphrase caching? I would be curious to see or be pointed to a discussion of it.
Is there a best practice that enables a better way to avoid even accidentally enabling the use of a cached passphrase?
Is there a way to use gpg2 without gpg-agent ever running?
Given that agents are daemons which are expected to be able to answer queries, what prevents another user or service running on the local machine from being able to access my cached or stored credentials?
Am I being overly paranoid about the use of passphrase caching? I would be curious to see or be pointed to a discussion of it.
Your concerns are certainly valid IMO. The good news is that there are ways to customize gpg-agent behaviour to suit your needs. For example, use a terminal-based passphrase prompt (PIN entry) instead of a GUI prompt and do not cache passphrases.
Is there a best practice that enables a better way to avoid even accidentally enabling the use of a cached passphrase?
A quick solution, likely not a best practice, is to customize your ~/.gnupg/gpg-agent.conf with the following options:
# Expire cached PINs (passphrases) after zero seconds
default-cache-ttl 0
max-cache-ttl 0
# If you use your GPG keys for SSH auth...
default-cache-ttl-ssh 0
max-cache-ttl-ssh 0
enable-ssh-support
# Use TTY-based PIN entry program (I see pinentry,
# pinentry-curses, pinentry-gnome3, pinentry-tty and
# pinentry-x11 on my system)
pinentry-program /usr/bin/pinentry-tty
I found the following guides on GPG key best practices (more of a general guide around key management, not exactly what you're asking) fairly informative and easy to follow:
https://alexcabal.com/creating-the-perfect-gpg-keypair/
https://riseup.net/en/security/message-security/openpgp/best-practices (somewhat dated, some sections don't work out of the box with latest gpg 2.x versions)
Is there a way to use gpg2 without gpg-agent ever running?
Not with gpg 2.x as far as I am aware of. The man page states the following:
--use-agent
--no-use-agent
This is dummy option. gpg always requires the agent.
I have gpg 2.1.15.
Given that agents are daemons which are expected to be able to answer queries, what prevents another user or service running on the local machine from being able to access my cached or stored credentials?
Good question... By default, gpg-agent uses a socket, so technically any process running as your user could in theory hijack your keys. Don't quote me on this, though. Here's an overview of how the gpg-agent works that will hopefully get you started on finding out the real answer:
https://unix.stackexchange.com/questions/188668/how-does-gpg-agent-work
According to https://wiki.archlinux.org/index.php/GnuPG#Unattended_passphrase in order to provide password directly to gpg - without gpg-agent running - you need to run with following options:
gpg --passphrase-fd 0 --pinentry-mode loopback ...
You need to provide password in console right after running this command. No password prompt will be visible during typing, but you will see typed password.
To hide password while typing you can wrap command in stty:
stty -echo ; gpg ... ; stty echo
I tested this with GnuPG v. 2.2.4: killed gpg-agent, shredded /usr/bin/gpg-agent, then run as described above. Worked well.
I've a fingerprint reader on my laptop and I installed fprintd to connect using it.
That works very well but there is this problem : When I remote connect to my laptop then I do a su/sudo command, I'm asking to swipe my finger. It works if I'm near the computer... but I'd prefer to disable it for cases I'm distant. Is there a way to do that ?
There is a bug filed for that in ubuntu which does not seem to have been resolved yet. That suggest there is no native way in fprint to do that. The workaround suggested by one user in there is to wait for the timeout.
From what I see pam can be configured in a certain way to fall back to password in case no print can be read by fprint. Archwiki says
auth sufficient pam_fprintd.so
auth include system-login
in /etc/pam.d/system-local-login not sure if that applies for your system too (for good measure here is someone configuring it in gentoo).So you should be able to allow pam to fall back on password with the right configuration.
I want to reiterate my comment for users that still don't know: Fingerprints (or biometrics in general) are not secure means of authentication (as the simpelest of the many flaws: you leave them all over your computer when you touch it).
There is a workaround:
Start two remote sessions.
On the first one, perform a sudo pwd. This will fire the fingerprint.
On the second, perform your desired command: sudo apt-get upgrade(or whatever). Since the fingerprint is blocked by the first session, it will skip directly to password authentication. No timeout.
I've installed git on Ubuntu 11.04 and I've cloned a private respository on GitHub. Whenever I try to push or pull to/from the repository, it takes about 30-60 seconds. Even if their are no changes in the repository. When using the same repository on Windows 7, pull/push requests only take a few seconds. I can't figure out what is wrong.
I've ran ssh -v git#github.com and it hangs right after this line:
debug1: SSH2_MSG_SERVICE_ACCEPT received
The above line will take 30-60 seconds to complete and then the remaining lines finish within a second. Here is the full output of ssh -vvv git#github.com: http://pastebin.com/LdY0EifW
I've already tried changing "GSSAPIAuthentication" to "no" and "UseDNS" to "no" in /etc/ssh/ssh_config. That didn't make any difference.
Any ideas?
It seems like the system might be running out of entropy.
SSH, like any other cryptographic application, needs some truly random numbers to be able to provide security. Linux kernel normally gathers some randomness (entropy) from precise timing of various events and makes it available via /dev/random, which ssh reads when it needs to create the session keys. On desktops there is usually enough entropy gathered, but if there is some other application that needs it, you might be running low and than reading /dev/random will take a lot of time, because it's waiting for enough entropy to be collected.
=> please verify by running strace ssh git#github.com whether it's actually waiting in read from `/dev/random. If yes, you have this problem.
If it's a server hosting any potentially sensitive data, you should probably equip it with hardware random number generator (e.g. the "entropy key"). You can also try to modify the random number generator settings to less secure ones (I believe there are some options to be set via /proc), but only if the server does not host customer data or any sensitive company data.
Edit: it looks more like a network problem somewhere.
I had a similar problem, although with all internet and not just push/pull of git. The problem was according to solutions to the same problem for many people either something with IPv6 or something with the driver:
So try these:
Disable IPv6. See here <--- Note only do this if you know you won't use IPv6. Also remember this so if you needed later you can enable it.*
Blacklist your driver. Follow this question for more instructions.
For me, the second case was the solution.
* I'm not sure what they shipped with Ubuntu 11.04, but there appears to be something wrong with DNS lookup when the network is in IPv4, but IPv6 is enabled, which makes it take a long time.
Every time I commit a file in svn I get the following message:
ATTENTION! Your password for authentication realm:
http://domainname.com:80 “domainname.com”
can only be stored to disk unencrypted! You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible. See the documentation for details.
You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in '/root/.subversion/servers'.
Store password unencrypted (yes/no)? no
I don't want this authentication; how can I get rid of this warning?
You are not storing the password in Subversion because you answered no to the question whether or not you want to store this password.
I take it you want to eliminate this error warning message entirely. There are two ways to handle that:
The easy, but hard way: You can specify svn --no-auth-cache each and every time you a Subversion command. It's easy to do since it requires no real action on your part. It's hard because you have to do this almost every time you use a Subversion command (especially one that touches the repository like checkout and commit).
The hard, but easy way: You can modify your user's Subversion configuration not to ask if you want to store this information. (BTW, why are you running as root? You like living life on the edge? Better off running as a user and configure sudo to allow you to do the root stuff you need. That way, you can track who's doing what, and you don't do something that could accidentally bring the server down. In fact, many Unix/Linux systems by default no longer allow a user to sign in as root. You have to do sudo). This is hard because you have to do something, but easy because once you do it, you don't have to do anything again.
You have the name of the file that you need to edit (/root/.subversion/servers). Look for the [global] section and look for the line # store-passwords = no and remove the # from the beginning of the line. You can also do the same for the # store-plaintext-passwords = no line and the # store-auth-cred = no line. While, you're at it, you can also delete the files under the auth directory which is where Subversion stores its credentials. This will completely eliminate already stored passwords. More information can be found in the on line Red Bean Subversion manual.
Now, when you do a Subversion command that touches the repository, it'll ask you for a user name and password and won't ask if you want to store them.
You copied the full warning message here. Reading it instead of just copy/pasting it would answer your question:
you can avoid future appearances of
this warning by setting the value of
the 'store-plaintext-passwords' option
to either 'yes' or 'no' in
'/root/.subversion/servers'.
The subversion client is only asking for authentication because the server requires it. To get rid of the authentication requirement, you'll have to change the server's configuration (e.g., in Apache, get rid of AuthType, AuthName, and AuthUserFile). You can use other authentication methods which do not require passwords (for example, client certificates).
If you just want to get rid of the save password unencrypted prompt, you can set store-plaintext-passwords=off (by editing ~/.subversion/config) or you can make encrypted passwords work by getting (on Unices) the GNOME keyring or KDE wallet running. On Windows, SVN should automatically use built-in NTFS encryption; on Mac OS X, the Keyring. See the Client Credentials section of the SVN Manual for further details.
You could also encrypt your home directory on Unix. Then the credentials would be encrypted as well (but of course available to any program running as you or root while you're logged in, similar to the NTFS encryption).
If you don't want SVN to store passwords at all, encrypted or not, set store-passwords=no in the SVN config file.