Comment savoir quelles clés gpg-agent a mis en cache? (comme ssh-add -l vous montre les clés ssh mises en cache)

40

ssh-add -lvous montre toutes les clés ssh qui ont été ajoutées avec ssh-add ~/.ssh/id_yourkey. Comment puis-je faire la même chose avec gpg et gpg-agent, autrement dit, lui demander d'afficher une liste de clés en cache?

gpg gpg-agent utilisateur3243135
la source

Réponses:

32

Vous ne pourrez peut-être pas le faire, du moins pas encore, ou du moins pas dans le cas général. Cependant, je partagerai ce que j'ai appris et j'espère pouvoir mettre à jour cette réponse le moment venu.

Tout d’abord, contrairement à la ssh-agentcapacité, qui cache en fait les clés privées, gpg-agentpeut mettre en cache des clés ou des phrases secrètes. Il appartient à chaque client de mettre en cache et gpgutilise uniquement gpg-agentpour mettre en cache la phrase secrète.

Vous pouvez interagir avec gpg-agentà l'aide de l' gpg-connect-agentutilitaire. Dans l'exemple qui suit, je passe des commandes une à une via 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

Lors de l'appel gpg-connect-agentet du passage de cette commande, la pinentrycommande configurée sur mon système utilise les chaînes d'erreur, d'invite et de description pour demander une phrase secrète. Dans ce cas, j'ai entré "MyPassPhrase", qui est renvoyé dans la sortie structurée (voir l'image ci-dessous) . Si j'envoie GET_PASSPHRASEà gpg-agentnouveau avec le même message $CACHEID, il retourne la phrase secrète en cache au lieu de l'utiliser pinentry.

                                 ss de la boite de dialogue

GET_PASSPHRASEaccepte également une --no-askoption qui renverra une erreur sur un cache manquant. Ici, j'utilise "NotCachedID" comme ID de cache et j'utilise des chaînes factices pour les arguments requis qui gpg-agentne seront pas utilisés.

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

En principe, vous pouvez demander à l'agent chaque phrase secrète éventuellement mise en cache, puis rechercher OKou ERRdans le résultat. La question devient alors, comment générer l'identifiant de cache? Comme nous le voyons dans l'exemple ci-dessus, gpg-agentson acceptation comme identifiant de cache est libérale. Il s'avère que gpgcalcule une empreinte digitale sur la clé publique et utilise une représentation sous forme de chaîne codée hexadécimale en tant qu'ID de cache, mais le problème est que cette empreinte digitale n'est pas la même que l'empreinte digitale que vous pouvez apprendre viagpg --fingerprint --list-secret-keys. Ce résumé est appelé keygrip (car il est calculé sur le matériau de clé brut uniquement, tandis que l'empreinte digitale est calculée sur le matériau de clé et l'horodatage de création). Si vous voulez vraiment continuer dans cette voie, vous devrez trouver comment générer la bonne empreinte digitale pour chacune des clés que vous souhaitez vérifier (ce sera facile avec la prochaine génération de GnuPG, 2.1, avec l'option --with-keygrip).

Avertissement: La sortie de GET_PASSPHRASEcontient réellement la phrase secrète en clair . Même si vous laissez cette --dataoption désactivée , la phrase secrète est clairement visible sous forme de chaîne codée en hexadécimal. C’est probablement une très mauvaise idée (tm) de se moquer de tout cela à moins de savoir ce que vous faites et de prendre les précautions appropriées.

Neirbowj
la source
Terrific answer! Cela fait des jours que je cherche et je ne trouve pas grand chose à ce sujet. Manière de tout mettre ensemble et de l'expliquer en termes clairs et concis!
slm
La capture d'écran n'est pas pinentry mais un programme GNOME interceptant gpg-agent, n'est-ce pas?
Hauke ​​Laging
gpg-agentinvoque le type de pinentryprogramme qu’il est configuré pour utiliser. Voir par exemple Comment forcer le mode console GPG à usage pinentry ... .
neirbowj
En utilisant gpg-2.1.11compilé à partir de la source sur Ubuntu 14.04, je ne peux pas comprendre l’ gpg-agentidentifiant du cache: j’ai essayé les deux poignées de clé (clé principale et sous-clé) et l’empreinte digitale de la clé, comme indiqué par gpg --fingerprint --with-keygrip <user>. Aucun d’entre eux ne fonctionne et fait gpg-connect-agenttoujours rapport ERR 67108922 No data <GPG Agent>. J'ai vérifié à nouveau que l'agent a toujours le mot de passe composé en s'exécutant correctement GPG_TTY= gpg --decrypt <file>après avoir essayé divers identifiants de cache. (En cas de doute, en déconfigurant GPG_TTY, le déchiffrement ne réussit que si la phrase secrète est déjà mise en cache par gpg-agent.)
Matei David
Est-ce que 2.0.14 pourrait être buggé? En utilisant la technique ci-dessus, gpg-agent a bien le mot de passe souhaité pour la clé spécifiée (identifiée par le keygrip), mais lorsque je tente de signer avec ce keygrip, je suis néanmoins invité à saisir un mot de passe. Pourquoi?
Otheus
8

Sur les versions ultérieures de gnupg (testé avec 2.1.18), utilisez:

gpg --fingerprint --with-keygrip <email>

pour obtenir la clé, puis

echo "KEYINFO --no-ask <keygrip> Err Pmt Des" | gpg-connect-agent

pour voir si c'est mis en cache ou pas.

Gimmesudo
la source
5

Sur les versions ultérieures de GnuPG (testé avec la version 2.2.9), il est également possible de répertorier les poignées de clé actuellement mises en cache par l'agent à l'aide de la commande keyinfo --listwith gpg-connect-agent.

$ gpg-connect-agent 'keyinfo --list' /bye
S KEYINFO 866C3DE249CF81E31A3691845DBADE2809487FF5 D - - 1 P - - -
S KEYINFO 04278155E72CAE8FF1548FE161F1B8F7673824F4 D - - - P - - -
OK

La 1septième colonne indique que la clé est mise en cache. L'association entre une poignée et la clé qu'elle représente peut être récupérée gpg --list-secret-keys --with-keygrip.

Source: https://demu.red/blog/2016/06/how-to-check-if-your-gpg-key-is-in-cache/

GeoffreyFrogeye
la source
3

Pour obtenir le cache, vous devez mentionner --fingerprintdeux fois, par exemple:

$ gpg --fingerprint --fingerprint [email protected]
pub   1024D/517D0F0E 2000-10-10
      Key fingerprint = C75D C40A 11D7 AF88 9981  ED5B C86B A06A 517D 0F0E
uid                  Linux Kernel Archives Verification Key <[email protected]>
sub   4096g/E50A8F2A 2000-10-10
      Key fingerprint = E851 4C25 10C6 0291 0D47  A008 7C8B 4360 E50A 8F2A

Le cacheid dans ce cas serait E8514C2510C602910D47A0087C8B4360E50A8F2A.

Ed Neville
la source
Cela a fonctionné pour moi
Matthew Hannigan
La réponse à l' adresse unix.stackexchange.com/a/342461/108198 semble meilleure.
Ben Creasy
Cela ne fonctionne pas pour moi ... un --fingerprintcontre deux --fingerprint --fingerprintrenvoie exactement le même résultat. Comme @BenCreasy écrit, la réponse ci-dessus en utilisant le keygrip fonctionne.
Trey