Jak mogę dowiedzieć się, jakie klucze buforował gpg-agent? (np. jak ssh-add -l pokazuje ci klucze ssh w pamięci podręcznej)

40

ssh-add -lpokazuje wszystkie klucze ssh, które zostały dodane za pomocą ssh-add ~/.ssh/id_yourkey. Jak zrobić analogiczne działanie z gpg i gpg-agent, innymi słowy, poprosić go o wyświetlenie listy kluczy w pamięci podręcznej?

użytkownik3243135
źródło

Odpowiedzi:

32

Możesz nie być w stanie tego zrobić, przynajmniej jeszcze nie, lub przynajmniej nie w ogólnym przypadku. Podzielę się jednak tym, czego się nauczyłem, i z niecierpliwością oczekuję aktualizacji tej odpowiedzi we właściwym czasie.

Przede wszystkim, w przeciwieństwie do ssh-agentfunkcji, która faktycznie buforuje klucze prywatne, gpg-agentmoże buforować klucze lub hasła. To do każdego klienta należy buforowanie, a gpgpo prostu używa gpg-agentdo buforowania hasła.

Możesz gpg-agentkorzystać z tego gpg-connect-agentnarzędzia. W poniższym przykładzie przekazuję polecenia pojedynczo za pośrednictwem 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

Po wywołaniu gpg-connect-agenti przekazaniu tego polecenia, pinentrypolecenie skonfigurowane w moim systemie używa ciągów błędów, monitów i opisów do monitowania o podanie hasła. W tym przypadku wpisałem „MyPassPhrase”, co jest zwracane w ustrukturyzowanym wyjściu (patrz obrazek poniżej) . Jeśli wyślę GET_PASSPHRASEto gpg-agentponownie z tym samym $CACHEID, zwróci buforowane hasło zamiast użycia pinentry.

                                 ss okna dialogowego

GET_PASSPHRASEakceptuje również --no-askopcję, która zwróci błąd przy braku pamięci podręcznej. Tutaj używam „NotCachedID” jako identyfikatora pamięci podręcznej i używam fikcyjnych łańcuchów dla wymaganych argumentów, gpg-agentktóre nie będą używane.

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

Zasadniczo możesz więc poprosić agenta o każde hasło, które może być w pamięci podręcznej, po kolei i sprawdzić, OKczy ERRw danych wyjściowych. Powstaje pytanie, jak wygenerować identyfikator pamięci podręcznej? Jak widzimy w powyższym przykładzie, gpg-agentjest liberalny w tym, co akceptuje jako identyfikator pamięci podręcznej. Okazuje się, że gpgoblicza odcisk palca na kluczu publicznym i używa szesnastkowej reprezentacji łańcucha jako identyfikatora pamięci podręcznej, ale problem polega na tym, że ten odcisk palca nie jest taki sam jak odcisk palca, którego można się nauczyćgpg --fingerprint --list-secret-keys. Ten skrót nazywa się keygrip (ponieważ jest obliczany tylko na podstawie surowego materiału klucza, podczas gdy odcisk palca jest obliczany na podstawie materiału klucza i znacznika czasu utworzenia). Jeśli naprawdę chcesz kontynuować tę ścieżkę, musisz dowiedzieć się, jak wygenerować prawidłowy odcisk palca dla każdego z klawiszy, które chcesz sprawdzić (będzie to łatwe dzięki nowej generacji GnuPG, 2.1, z opcją --with-keygrip).

Ostrzeżenie: Dane wyjściowe GET_PASSPHRASEfaktycznie zawierają hasło w postaci niezaznaczonej . Nawet jeśli zrezygnujesz z tej --dataopcji, hasło jest wyraźnie widoczne jako ciąg znaków w kodzie szesnastkowym. Prawdopodobnie jest to bardzo zły pomysł (tm), jeśli nie wiesz, co robisz, i nie podejmiesz odpowiednich środków ostrożności.

neirbowj
źródło
Wspaniała odpowiedź! Szukałem od wielu dni i nie mogłem wiele na ten temat znaleźć. Sposób, aby złożyć wszystko w całość i wyjaśnić w jasny i zwięzły sposób!
slm
Zrzut ekranu nie jest ostry, ale przechwytuje jakiś program GNOME gpg-agent, prawda?
Hauke ​​Laging
gpg-agentwywołuje dowolny smak pinentryprogramu, z którego jest skonfigurowany. Patrz np Jak zmusić GPG do trybu konsoli stosowanie pineentry ... .
neirbowj
Korzystając gpg-2.1.11z kompilacji ze źródła na Ubuntu 14.04, nie mogę zrozumieć, jaki gpg-agentjest identyfikator pamięci podręcznej: wypróbowałem zarówno keygrips (klucz główny i podklucz), jak i odcisk palca klucza, jak pokazano przez gpg --fingerprint --with-keygrip <user>. Żadne z nich nie działa i gpg-connect-agentzawsze zgłasza ERR 67108922 No data <GPG Agent>. Dokładnie sprawdziłem, czy agent nadal ma hasło, uruchamiając się GPG_TTY= gpg --decrypt <file>po wypróbowaniu różnych identyfikatorów pamięci podręcznej. (W przypadku niejasności dezaktywacja powoduje GPG_TTYdeszyfrowanie tylko wtedy, gdy hasło jest już w pamięci podręcznej gpg-agent).
Matei David
Czy błąd 2.0.14 może być nieprawidłowy? Korzystając z powyższej techniki, gpg-agent rzeczywiście ma żądane hasło dla określonego klucza (identyfikowanego przez keygrip), ale kiedy próbuję się podpisać za pomocą tego keygripa, mimo to pojawia się monit o hasło. Czemu?
Otheus,
8

W nowszych wersjach gnupg (testowanych z 2.1.18) użyj:

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

aby zdobyć klucz

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

aby sprawdzić, czy jest w pamięci podręcznej, czy nie.

gimmesudo
źródło
5

W nowszych wersjach GnuPG (testowanych w wersji 2.2.9) można również wyświetlić listę klawiszy, które są obecnie buforowane przez agenta za pomocą polecenia keyinfo --listz gpg-connect-agent.

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

1W siódmej kolumnie wskazuje, że keygrip jest buforowane. Powiązanie między uchwytem klucza a kluczem, który reprezentuje, można odzyskać gpg --list-secret-keys --with-keygrip.

Źródło: https://demu.red/blog/2016/06/how-to-check-if-your-gpg-key-is-in-cache/

Geoffrey Frogeye
źródło
3

Aby uzyskać cacheid, musisz --fingerprintdwukrotnie wspomnieć , na przykład:

$ 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

W tym przypadku cacheid byłby E8514C2510C602910D47A0087C8B4360E50A8F2A.

Ed Neville
źródło
To zadziałało dla mnie
Matthew Hannigan,
Odpowiedź na unix.stackexchange.com/a/342461/108198 wydaje się lepsza.
Ben Creasy
To nie działa dla mnie ... jeden na --fingerprintdwóch --fingerprint --fingerprintzwraca dokładnie ten sam wynik. Jak pisze @BenCreasy, powyższa odpowiedź przy użyciu keygrip działa.
Trey