ssh-add -l
mostra tutti i tasti ssh che sono stati aggiunti con ssh-add ~/.ssh/id_yourkey
. Come posso fare la cosa analoga con gpg e gpg-agent, in altre parole, chiedergli di mostrare un elenco di chiavi memorizzate nella cache?
ssh-add -l
mostra tutti i tasti ssh che sono stati aggiunti con ssh-add ~/.ssh/id_yourkey
. Come posso fare la cosa analoga con gpg e gpg-agent, in altre parole, chiedergli di mostrare un elenco di chiavi memorizzate nella cache?
Risposte:
Potresti non essere in grado di farlo, almeno non ancora, o almeno non nel caso generale. Tuttavia, condividerò ciò che ho appreso e non vedo l'ora di aggiornare questa risposta a tempo debito.
Innanzitutto, a differenza della ssh-agent
funzionalità, che in realtà memorizza nella cache chiavi private, è gpg-agent
possibile memorizzare nella cache chiavi o passphrase. Spetta a ciascun client memorizzare nella cache e gpg
utilizza solo gpg-agent
per memorizzare la passphrase.
È possibile interagire con gpg-agent
l' gpg-connect-agent
utilità. Nell'esempio che segue, sto passando i comandi uno alla volta tramite 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
Quando si richiama gpg-connect-agent
e si passa a questo comando, il pinentry
comando configurato sul mio sistema utilizza le stringhe di errore, prompt e descrizione per richiedere una passphrase. In questo caso ho inserito "MyPassPhrase" che è ciò che viene restituito nell'output strutturato (vedi immagine sotto) . Se invio GET_PASSPHRASE
di gpg-agent
nuovo con lo stesso $CACHEID
, restituisce la passphrase memorizzata nella cache invece di utilizzare pinentry
.
GET_PASSPHRASE
accetta anche --no-ask
un'opzione che restituirà un errore in caso di mancata memorizzazione nella cache. Qui utilizzo "NotCachedID" come ID cache e utilizzo stringhe fittizie per gli argomenti richiesti che gpg-agent
non verranno utilizzati.
$ echo "GET_PASSPHRASE --no-ask NotCachedID Err Pmt Des" | gpg-connect-agent
ERR 67108922 No data <GPG Agent>
In linea di principio, quindi, è possibile richiedere a turno all'agente ogni passphrase forse memorizzata nella cache e verificare OK
o ERR
nell'output. La domanda diventa quindi: come posso generare l'ID cache? Come vediamo nell'esempio sopra, gpg-agent
è liberale in ciò che accetta come ID cache. Si scopre che gpg
calcola un'impronta digitale sulla chiave pubblica e utilizza una rappresentazione di stringa con codice esadecimale come ID cache, ma il problema è che questa impronta digitale non è la stessa dell'impronta digitale che puoi imparare tramitegpg --fingerprint --list-secret-keys
. Questo digest si chiama keygrip (perché viene calcolato solo sul materiale chiave grezzo mentre l'impronta digitale viene calcolata sul materiale chiave e sul timestamp di creazione). Se vuoi davvero continuare su questo percorso, dovrai scoprire come generare l'impronta digitale corretta per ciascuno dei tasti che desideri controllare (questo sarà facile usando la prossima generazione di GnuPG, 2.1, con l'opzione --with-keygrip
).
Avvertenza: l'output di GET_PASSPHRASE
effettivamente contiene la passphrase in chiaro . Anche se si lascia l' --data
opzione, la passphrase è chiaramente visibile come una stringa con codice esadecimale. Probabilmente è una pessima idea (tm) scherzare con questo a meno che tu non sappia cosa stai facendo e prendere le precauzioni appropriate.
gpg-agent
, vero?
gpg-agent
invoca qualunque tipo di pinentry
programma sia configurato per l'uso. Si veda ad esempio Come forzare GPG alla modalità console utilizzo pinentry ... .
gpg-2.1.11
compilato dal sorgente su Ubuntu 14.04, non riesco a capire quale sia l' gpg-agent
ID cache: ho provato sia i keygrip (chiave principale e sottochiave) sia l'impronta digitale della chiave, come mostrato da gpg --fingerprint --with-keygrip <user>
. Nessuno di loro funziona e gpg-connect-agent
riporta sempre ERR 67108922 No data <GPG Agent>
. Ho ricontrollato che l'agente abbia ancora la passphrase eseguendo correttamente GPG_TTY= gpg --decrypt <file>
dopo aver provato vari ID cache. (Nel caso in cui non sia chiaro, disattivando GPG_TTY
, la decrittografia ha esito positivo solo se la passphrase è già memorizzata nella cache dagpg-agent
.)
Nelle versioni successive di GnuPG (testato con 2.2.9) è anche possibile elencare i keygrip che sono attualmente memorizzati nella cache dall'agente usando il comando keyinfo --list
con gpg-connect-agent
.
$ gpg-connect-agent 'keyinfo --list' /bye
S KEYINFO 866C3DE249CF81E31A3691845DBADE2809487FF5 D - - 1 P - - -
S KEYINFO 04278155E72CAE8FF1548FE161F1B8F7673824F4 D - - - P - - -
OK
L' 1
nella settima colonna indica che il keygrip viene memorizzato nella cache. L'associazione tra un keygrip e la chiave che rappresenta può essere recuperata con gpg --list-secret-keys --with-keygrip
.
Fonte: https://demu.red/blog/2016/06/how-to-check-if-your-gpg-key-is-in-cache/
Per ottenere il cacheid è necessario menzionare --fingerprint
due volte, ad esempio:
$ gpg --fingerprint --fingerprint ftpadmin@kernel.org
pub 1024D/517D0F0E 2000-10-10
Key fingerprint = C75D C40A 11D7 AF88 9981 ED5B C86B A06A 517D 0F0E
uid Linux Kernel Archives Verification Key <ftpadmin@kernel.org>
sub 4096g/E50A8F2A 2000-10-10
Key fingerprint = E851 4C25 10C6 0291 0D47 A008 7C8B 4360 E50A 8F2A
Il cacheid in questo caso sarebbe E8514C2510C602910D47A0087C8B4360E50A8F2A
.
--fingerprint
contro due --fingerprint --fingerprint
restituiscono entrambi esattamente lo stesso risultato. Come scrive @BenCreasy, la risposta sopra usando il keygrip funziona.
http://lists.gnupg.org/pipermail/gnupg-users/2010-January/037876.html
Il cacheid è l'impronta digitale completa della chiave.
gpg --fingerprint user@foo.bar