ssh-add -lmuestra todas las teclas ssh que se han agregado con ssh-add ~/.ssh/id_yourkey. ¿Cómo hago lo análogo con gpg y gpg-agent, en otras palabras, pedirle que muestre una lista de claves en caché?
¿Cómo puedo averiguar qué claves ha guardado en caché gpg-agent? (como cómo ssh-add -l muestra las claves ssh almacenadas en caché)
Respuestas:
Es posible que no pueda hacer esto, al menos no todavía, o al menos no en el caso general. Sin embargo, compartiré lo que he aprendido y espero actualizar esta respuesta a su debido tiempo.
En primer lugar, a diferencia de la ssh-agentcapacidad, que realmente almacena en caché las claves privadas, gpg-agentpuede almacenar en caché las claves o las frases de contraseña. Depende de cada cliente qué almacenar en caché, y gpgsolo se utiliza gpg-agentpara almacenar en caché la frase de contraseña.
Puede interactuar con el gpg-agentuso de la gpg-connect-agentutilidad. En el ejemplo que sigue, paso comandos uno por uno a través de 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
Al invocar gpg-connect-agenty pasar este comando, el pinentrycomando configurado en mi sistema utiliza las cadenas de error, solicitud y descripción para solicitar una frase de contraseña. En este caso, ingresé "MyPassPhrase", que es lo que se devuelve en la salida estructurada (ver imagen a continuación) . Si envío GET_PASSPHRASEde gpg-agentnuevo con lo mismo $CACHEID, devuelve la frase de contraseña en caché en lugar de usar pinentry.
GET_PASSPHRASETambién acepta una --no-askopción que devolverá un error en un error de caché. Aquí uso "NotCachedID" como ID de caché, y uso cadenas ficticias para los argumentos requeridos que gpg-agentno se usarán.
$ echo "GET_PASSPHRASE --no-ask NotCachedID Err Pmt Des" | gpg-connect-agent
ERR 67108922 No data <GPG Agent>
En principio, entonces, podría pedirle al agente por cada frase de contraseña almacenada en caché a su vez, y verificar OKo ERRen la salida. La pregunta es, ¿cómo genero la ID de caché? Como vemos en el ejemplo anterior, gpg-agentes liberal en lo que acepta como ID de caché. Resulta que gpgcalcula una huella digital en la clave pública y utiliza una representación de cadena codificada en hexadecimal como ID de caché, pero el problema es que esta huella digital no es la misma que la huella digital que puede aprender a través degpg --fingerprint --list-secret-keys. Este resumen se denomina keygrip (porque se calcula sobre el material de la clave sin procesar solo mientras que la huella digital se calcula sobre el material de la clave y la marca de tiempo de creación). Si realmente desea continuar por este camino, tendrá que descubrir cómo generar la huella digital correcta para cada una de las teclas que desea verificar (esto será fácil con la próxima generación de GnuPG, 2.1, con la opción --with-keygrip).
Advertencia: La salida de GET_PASSPHRASErealmente contiene la frase de contraseña en claro . Incluso si deja de lado la --dataopción, la frase de contraseña es claramente visible como una cadena codificada en hexadecimal. Probablemente sea una muy mala idea (tm) jugar con esto a menos que sepa lo que está haciendo y tome las precauciones adecuadas.
¡Excelente respuesta! He estado buscando durante días y no pude encontrar mucho sobre esto. ¡Manera de poner todo junto y explicarlo en términos claros y concisos!
—
slm
La captura de pantalla no es pinentry, pero algunos programas de GNOME interceptan
—
Hauke Laging
gpg-agent, ¿verdad?
gpg-agentinvoca cualquier sabor del pinentryprograma que está configurado para usar. Véase, por ejemplo Cómo forzar GPG para el modo de utilización de la consola pinentry ... .
Utilizando
—
Matei David
gpg-2.1.11compilado de la fuente en Ubuntu 14.04, no puedo entender cuál es la gpg-agentidentificación de la memoria caché: probé tanto las teclas de agarre (tecla principal y la subclave) como la huella digital de la llave, como se muestra en gpg --fingerprint --with-keygrip <user>. Ninguno de ellos funciona, y gpg-connect-agentsiempre informa ERR 67108922 No data <GPG Agent>. Verifiqué dos veces que el agente todavía tiene la frase de contraseña ejecutándose con éxito GPG_TTY= gpg --decrypt <file>después de probar varios identificadores de caché. (En caso de que no esté claro, al desarmar GPG_TTY, el descifrado tiene éxito solo si la frase de contraseña ya está almacenada en caché gpg-agent.)
¿Podría 2.0.14 tener errores? Usando la técnica anterior, gpg-agent sí tiene la frase de contraseña deseada para la clave especificada (identificada por el keygrip), pero cuando intento firmar con ese keygrip, no obstante, se me solicita una contraseña. ¿Por qué?
—
Oteo
En versiones posteriores de GnuPG (probado con 2.2.9), también es posible enumerar los keygrips que el agente almacena actualmente en caché utilizando el comando keyinfo --listwith gpg-connect-agent.
$ gpg-connect-agent 'keyinfo --list' /bye
S KEYINFO 866C3DE249CF81E31A3691845DBADE2809487FF5 D - - 1 P - - -
S KEYINFO 04278155E72CAE8FF1548FE161F1B8F7673824F4 D - - - P - - -
OK
El 1en la séptima columna indica que el keygrip está en caché. La asociación entre un keygrip y la clave que representa se puede recuperar con gpg --list-secret-keys --with-keygrip.
Fuente: https://demu.red/blog/2016/06/how-to-check-if-your-gpg-key-is-in-cache/
Para obtener el cacheid, debe mencionar --fingerprintdos veces, por ejemplo:
$ 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
El cacheid en este caso sería E8514C2510C602910D47A0087C8B4360E50A8F2A.
Esto funcionó para mí
—
Matthew Hannigan, el
La respuesta en unix.stackexchange.com/a/342461/108198 parece mejor.
—
Ben Creasy
Esto no funciona para mí ... uno
—
Trey
--fingerprintcontra dos --fingerprint --fingerprintdevuelven exactamente la misma salida. Como escribe @BenCreasy, la respuesta anterior utilizando el keygrip funciona.
http://lists.gnupg.org/pipermail/gnupg-users/2010-January/037876.html
El cacheid es la huella digital completa de la clave.
gpg --fingerprint user@foo.bar