Cum funcționează agentul GPG?

Gpg-agent este un program care rulează în fundal (un daemon ) și stochează cheile secrete GPG în memorie. Când un proces GPG are nevoie de cheie, acesta contactează programul gpg-agent care rulează printr-un socket și solicită cheia. Dacă procesul de agent are cheia, aceasta o furnizează către gpg. Dacă nu, încearcă să încarce cheia criptată de pe cheia dvs. și vă solicită fraza de acces a cheii. Odată ce agentul a obținut cheia decriptată, aceasta o transmite procesului gpg. În plus față de cheile GPG, agentul Gpg poate stoca în mod similar cheile SSH și le poate furniza proceselor SSH, cum ar fi ssh-agent program care vine cu SSH.

Punctul principal al utilizării unui agent cheie este astfel încât să Nu trebuie să introduceți fraza de acces de fiecare dată când utilizați cheia. Agentul păstrează cheia în memorie de la o dată la alta. GPG în sine nu poate face asta, deoarece procesul se termină odată ce și-a făcut treaba.

Un alt lucru pe care îl poate face un agent cheie este să permită GPG care rulează pe o mașină la distanță să obțină chei în agentul local ( care le poate încărca dintr-un fișier local și vă poate solicita expresia de acces). Gpg-agent încă nu poate face acest lucru, este o caracteristică planificată . SSH are redirecționare de agent de foarte mult timp. (Acesta este un motiv pentru a nu utilizați gpg-agent pentru cheile SSH.)

GPG 1.x sau 2.0.x știe că agentul rulează deoarece variabila GPG_AGENT_INFO este setată. Această variabilă conține locația socketului pentru a comunica cu agentul, precum și ID-ul procesului agentului. GPG 2.1 plasează întotdeauna socketul agentului în ~/.gnupg. GPG 2.x pornește întotdeauna un agent proces dacă nu se execută.

Puteți porni agentul pur și simplu executând gpg-agent. Dacă doriți să păstrați un proces de agent ca parte a sesiunii dvs., puteți înlocui invocarea managerului de sesiune cu gpg-agent my-session-manager; unele distribuții configurează acest lucru automat. GPG va porni automat agentul, iar GPG 2.1 va găsi suplimentar un agent care rulează fără a avea nevoie de o variabilă de mediu, deci nu trebuie să-l porniți în acest fel decât dacă utilizați o versiune mai veche de GPG sau dacă utilizați agentul pentru a stoca alte tipuri de chei precum SSH.

Puteți trimite agentul comenzi cu gpg-connect-agent shell. Trimiteți comanda kill la ucideți procesul agentului (sau trimiteți-i un semnal).

Gpg-agent este livrat cu GPG în sine. Unele distribuții îl împachetează separat.

Comentarii

• " Când un proces GPG are nevoie de cheie, acesta contactează programul gpg-agent care rulează printr-un soclu și solicită cheia. Dacă procesul agent are cheia, îl oferă gpg. " Ușor înșelător. Agentul nu furnizează o cheie pentru procesul clientului. În schimb, este perfect organizează acțiuni folosind cheia, în numele procesului clientului. (Clientul oferă agentului ceva de semnat, criptat sau decriptat, iar agentul face acest lucru.) Când utilizați un agent, software-ul client SSH și GPG nu câștigă niciodată accesul la cheia reală.
• " Gpg-agent nu poate ' încă face acest lucru, este o caracteristică planificată. SSH are agent de redirecționare de foarte mult timp. (Acesta este un motiv pentru care nu se folosește gpg-agent pentru cheile SSH.) " Nu chiar adevărat. gpg-agent funcționează bine cu redirecționarea agentului SSH. Îl folosesc în fiecare zi. Clientul SSH se ocupă de redirecționare, gpg-agent nu este cu adevărat implicat în asta. Ceea ce nu este acceptat este ca GPG în sine să vorbească de la distanță cu un agent.