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

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?

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.

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.

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.

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/

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

$ 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

W tym przypadku cacheid byłby E8514C2510C602910D47A0087C8B4360E50A8F2A.

http://lists.gnupg.org/pipermail/gnupg-users/2010-J stycznia/037876.html

Cacheid to pełny odcisk palca klucza.

gpg --fingerprint user@foo.bar