What are the steps needed to cache passphrases entered via pinentry using gpg-preset-passphrase in 2.1.15

gpggpg-agent

I'm seeking to cache passphrases for use on an unattended machine. As doing this poses some risk, I'd prefer choosing which passphrases get cached and avoid setting both default-cache-ttl and max-cache-ttl to obnoxiously high values as well as avoid needing to clear gpg-agent's entire cache periodically – hence I'm looking for a solution with gpg-preset-passphrase. Some of the information I found while troubleshooting refer to older versions of GnuPG so I'm unsure if I have sufficiently accounted for all the differences.

First, as prescribed by man 1 gpg-agent, I have export GPG_TTY=$(tty) in my .bashrc.

Now suppose I run eval $(gpg-agent --daemon --allow-preset-passphrase --default-cache-ttl 1 --max-cache-ttl 31536000) to start gpg-agent, noting that gpg-preset-passphrase still honors –max-cache-ttl (default 2 hours).

I then get the keygrip $KEYGRIP of the desired secret subkey with gpg --with-keygrip -K.

With that I try /path/to/gpg-preset-passphrase -c $KEYGRIP. Upon hitting return, this prints:

   gpg-preset-passphrase: caching passphrase failed: Not implemented

Attempting again adding --verbose --debug 6 --log-file /path/to/gpg-agent.log to gpg-agent, my log is appended with

   gpg-agent[4206] listening on socket /run/user/1000/gnupg/S.gpg-agent
   gpg-agent[4207] gpg-agent (GnuPG) 2.1.15 started
   gpg-agent[4207] handler 0x7f86ef783700 for fd 5 started
   gpg-agent[4207] command PRESET_PASSPHRASE failed: Not implemented
   gpg-agent[4207] handler 0x7f86ef783700 for fd 5 terminated

I'm unsure where to proceed from this apart from diving deeper into the source, so I'm wondering if anyone can first correct the steps I'm taking.

Best Answer

It sounds like you want to send the passphrase to gpg-preset-passphrase over stdin, without echoing it (to avoid exposing it in process list):

/path/to/gpg-preset-passphrase -c $KEYGRIP <<< $PASSPHRASE

If you care about portability outside of bash:

/path/to/gpg-preset-passphrase -c $KEYGRIP <<EOF
$PASSPHRASE
EOF

This answer about "Here Documents" syntax (EOF) was invaluable to me: https://unix.stackexchange.com/a/88492

You also need allow-preset-passphrase in your ~/.gnupg/gpg-agent.conf as mentioned by holms.

If you're looking to do this with symmetric encryption (since I already lost my sanity to this, maybe you won't have to), see my answer here w.r.t. finding the right keygrip/cacheid to use to preset the passphrase in gpg-agent: https://superuser.com/a/1485486/1093343

Related Solutions

Linux – gnupg 2.1.16 blocks waiting for entropy

I think I know what's going on. In gnupg's agent/gpg-agent.c, this function processes messages from libgcrypt.

/* This is our callback function for gcrypt progress messages.  It is
   set once at startup and dispatches progress messages to the
   corresponding threads of the agent.  */
static void 
agent_libgcrypt_progress_cb (void *data, const char *what, int printchar,
                             int current, int total)
{
  struct progress_dispatch_s *dispatch;
  npth_t mytid = npth_self ();

  (void)data;

  for (dispatch = progress_dispatch_list; dispatch; dispatch = dispatch->next)
    if (dispatch->ctrl && dispatch->tid == mytid)
      break;
  if (dispatch && dispatch->cb)
    dispatch->cb (dispatch->ctrl, what, printchar, current, total);

  /* Libgcrypt < 1.8 does not know about nPth and thus when it reads
   * from /dev/random this will block the process.  To mitigate this
   * problem we take a short nap when Libgcrypt tells us that it needs
   * more entropy.  This way other threads have chance to run.  */
#if GCRYPT_VERSION_NUMBER < 0x010800 /* 1.8.0 */
  if (what && !strcmp (what, "need_entropy"))
    npth_usleep (100000); /* 100ms */
#endif
}

That last part with npth_usleep was added between 2.1.15 and 2.1.17. Since this is conditionally compiled if libgcrypt is older than 1.8.0, the straightforward fix would be recompiling gnupg against libgcrypt 1.8.0 or later… unfortunately that version doesn't seem to exist yet.

The weird thing is, that comment about libgcrypt reading /dev/random is not true. Stracing the agent reveals it's reading from /dev/urandom and using the new getrandom(2) syscall, without blocking. It does however send many need_entropy messages, causing npth_usleep to block. Deleting those lines fixes the issue.

I should mention that npth seems to be some kind of cooperative multitasking library, and npth_usleep is probably its way to yield, so it might be better to just significantly reduce that delay, just in case libgcrypt decides to block some day. (1ms is not noticeable)

GPG SSH Configuration – Use GPG Auth Subkeys with pinentry in tmux

The problem is that you are calling gpg-connect-agent updatestartuptty every time you open a terminal, so pinentry points itself to the latest shell.

What you actually want is not the latest shell terminal, but the one you are connecting from (when calling ssh)

For that the easiest way is telling .ssh/config to execute the update command from the tty you are connecting. This is the magic line you are missing:

Match host * exec "gpg-connect-agent UPDATESTARTUPTTY /bye"

Best Answer

Related Solutions

Linux – gnupg 2.1.16 blocks waiting for entropy

GPG SSH Configuration – Use GPG Auth Subkeys with pinentry in tmux

Related Question