40

I've tried:

  • the SIGHUP method --> no succes
  • the cache timeout in gpg-agent.conf --> it seems that this file is not read, althougt I have the 'use-agent' line in gpg.conf

What should I do ?

Thomas Produit
  • 535
  • 1
  • 4
  • 7
  • The default GPG agent in Ubuntu is Seahorse. AFAIK, Seahorse does not read any gpg-agent.conf file. So I want to ask: what is your GPG agent? Are you sure it is confgured properly? Where are you sending SIGHUP? – Andrea Corbellini Sep 24 '13 at 21:43
  • @AndreaCorbellini I'm refering to the password agent which is gpg-agent and I don't know if it is properly configured because I don't know what properly configured exactly means for gpg-agent... Finally I'm sending SIGHUP using "pkill -SIGHUP gpg-agent" – Thomas Produit Sep 24 '13 at 21:51
  • 2
    The suggested answer below using gpg-connect-agent does indeed seem to work for seahorse (at least for me on 14.04), not just gpg-agent. This means that without disabling gnome-keyring you should be able to use it out of the box. – Greg Feb 05 '15 at 13:06

4 Answers4

68

for those really using gpg-agent, you can forget passphrases with:

echo RELOADAGENT | gpg-connect-agent
Matija Nalis
  • 1,444
  • 3
    Thank you! That works just fine for gnome-keyring-daemon too (on 14.04) - I've looked everywhere to find a simple "forget"! – Greg Feb 05 '15 at 13:03
  • I get ERR 103 unknown command. – zondo Nov 13 '16 at 13:58
  • 1
    Thank you very much for this simple and effective "forget" tool. All the methods discussed above regarding how to manage caching of gpg passwords misses the fundamental point that we should never ever allow passwords to be cached in the first place. –  Jul 12 '17 at 20:47
  • This actually helped me out on Windows. Thank you. – Paul Williams Jul 24 '19 at 01:50
  • 1
    Note that this does not clear your password from memory. Gpg-agent will prompt you again, pretending it has forgotten, but it hasn't. I assume people want to clear the cached password to protect against an attacker that can invoke gpg-agent or read the memory, but if an attacker can invoke gpg-agent (because your laptop is unlocked) or get your RAM (because you're out for lunch), they can also just get the password from memory or wrap the pinentry program to capture it. – Luc Mar 05 '20 at 14:49
  • @Luc no, you clear password so apps can no longer authenticate without someone reentering correct passphrase, which this will do. If attacker has hardware access, you're out of luck as they can sniff memory bus and thus you entering passphrase, as well as encypted key. If they have root, they can do the same, or replace gpg-agent binaries to send them unencrypted keys even if you use FDE. And even if they have just cracked your user account, they can easily capture your passphrase as well as your encrypted key while you enter it. No way any passphrase clearing would protect you from that. – Matija Nalis Mar 06 '20 at 20:42
  • @MatijaNalis "you clear password so apps can no longer authenticate" those apps are already running on your machine. I think we mostly agree: you say "even if they have just cracked your user account, they can easily capture your passphrase". Replace "they" by "malicious apps" and you've got the same scenario. I cannot think of any scenario in which it helps to issue "reloadagent" or sighup or equivalent, since malicious software or an attacker can get the keys anyway. – Luc Mar 07 '20 at 10:25
  • @Luc so if I get your reasoning correctly, your point is actually that having passphrase on a private key is useless concept by itself ? Because, if the program using it is malicious, or the user account is cracked, it doesn't mater if your provide program with encrypted private key + passphrase, or with unencrypted key, right? Attacker will just store unencrypted key privately for their nefarious use first time they see the passphrase. (Using a caching gpg-agent does not change the issue). You may want to ask on security.stackexchange.com about use cases of passphrases on private keys. – Matija Nalis Mar 07 '20 at 20:22
  • 1
    Good! It works also on Windows, when I use gpg from the git bash. – Antonio Jul 12 '21 at 09:27
30

GPG: In a single command:

gpg-connect-agent reloadagent /bye

SSH: for ssh agent you probably want those two:

ssh-add -D    #delete identities
ssh-agent -k  #kill ssh-agent
DrBeco
  • 492
  • 5
  • 8
  • 2
    I wonder why they did not make this easier using gpg itself. Example: gpg --clear-password-cache – MaXi32 Mar 09 '21 at 16:49
10

Let me begin by saying I had the exact same issue...

Your GPG secrets are probably being handled by the Gnome Keyring, even if gpg-agent is running. This answer provides some details on the available options for it.

Another way is to disable the GPG component of the Gnome Keyring, so that gpg-agent is used:

  • You can do this by removing (or renaming to something other than *.desktop) the file /etc/xdg/autostart/gnome-keyring-gpg.desktop.
  • It's possible you already have the necessary settings for gpg-agent to autostart. At least for me, running Ubuntu 13.04, that's true. However, if you need to, refer this post for some information on how to configure it.
  • After logging off and on again, just gpg-agent should be running, and it does respond both to settings in ~/.gnupg/gpg-agent.conf and to SIGHUP signals.
  • On a final note, it may be wise to also disable the SSH component of Gnome Keyring, since:
    • You probably also don't want your SSH keys unlocked for the whole session, and might want to use/configure ssh-agent or gpg-agent
    • It's possible that your configuration for gpg-agent autostart already includes SSH support (the default one in Ubuntu 13.04 does)
Community
  • 1
Jonas Malaco
  • 1,453
  • 1
  • 13
  • 15
  • I'm struggling with this issue. Under Ubuntu 18.04 the gnome-keyring-gpg.desktop file does not exist. – Linter Aug 10 '18 at 13:58
7
gpgconf --reload gpg-agent

This works for me ... hope this answers your question.

Koshin
  • 73