Как я могу узнать то, что кэшировал gpg-агент ключей? (как то, как ssh-добавляют, что-l показывает кэширование ssh ключей),

Вы не можете делать это, по крайней мере еще, или по крайней мере не в общем случае. Однако я совместно использую то, что я изучил и надеюсь обновить этот ответ в свое время.

В первую очередь, в отличие от этого, ssh-agent возможность, который на самом деле закрытые ключи кэшей, gpg-agent может кэшировать или ключи или пароли. Это до каждого клиента, чтобы кэшироваться, и gpg просто использование gpg-agent кэшировать пароль.

Можно взаимодействовать с gpg-agent использование gpg-connect-agent утилита. В примере, который следует, я передаю команды по одному через STDIN.

$ CACHEID="ThisIsTheTrickyPart"
$ ERRSTR="Error+string+goes+here"
$ PMTSTR="Prompt"
$ DESSTR="Description+string+goes+here"
$ echo "GET_PASSPHRASE --data $CACHEID $ERRSTR $PMTSTR $DESSTR" | gpg-connect-agent
D MyPassPhrase
OK

После вызова gpg-connect-agent и передача в этой команде, pinentry команда, настроенная в моей системе, использует ошибку, подсказку и строки описания для запроса пароль. В этом случае я ввел "MyPassPhrase", который является тем, что возвращается в структурированном выводе (см. изображение ниже). Если я отправляю GET_PASSPHRASE кому: gpg-agent снова с тем же $CACHEID, это возвращает кэшируемый пароль вместо использования pinentry.

GET_PASSPHRASE также принимает a --no-ask опция, которая возвратит ошибку на неудачном обращении в кэш. Здесь я использую "NotCachedID" в качестве идентификатора кэша и использую фиктивные строки для обязательных аргументов это gpg-agent не будет использовать.

$ echo "GET_PASSPHRASE --no-ask NotCachedID Err Pmt Des" | gpg-connect-agent
ERR 67108922 No data <GPG Agent>

В принципе, затем, Вы могли попросить у агента каждого возможно кэшируемого пароля в свою очередь и проверить на OK или ERR в выводе. Вопрос затем становится, как я генерирую идентификатор кэша? Поскольку мы видим в примере выше, gpg-agent либерально в том, что это принимает как идентификатор кэша. Это оказывается этим gpg вычисляет цифровой отпечаток на открытом ключе и использует кодированное шестнадцатеричными числами строковое представление в качестве идентификатора кэша, но проблема состоит в том, что этот цифровой отпечаток не является тем же как цифровым отпечатком, через который можно учиться gpg --fingerprint --list-secret-keys. Этот обзор называют keygrip (потому что он вычисляется по необработанному ключевому материалу только, тогда как цифровой отпечаток является calculcated по ключевому материалу и метке времени создания). Если Вы действительно хотите продолжить вниз этот путь, необходимо будет узнать, как генерировать корректный цифровой отпечаток для каждого из ключей, которые Вы хотите проверить (это будет легким использованием следующего поколения GnuPG, 2.1, с опцией --with-keygrip).

Предупреждение: вывод от GET_PASSPHRASE на самом деле содержит пароль в ясном. Даже если Вы кончаете --data опция, пароль явно видим как кодированная шестнадцатеричными числами строка. Это - вероятно, Очень Плохая Идея (TM) для слоняний без дела с этим, если Вы не знаете то, что Вы делаете и принимаете соответствующие меры предосторожности.