Jag har en rad i min gpg.conf-fil som säger use-agent.
Jag förstår att detta hänvisar till gpg-agent som är en demon. Man-sidan säger ”gpg-agent är en demon för att hantera hemliga (privata) nycklar oberoende av vilket protokoll som helst. Den används som en backend för gpg och gpgsm samt för ett par andra verktyg.”

Kan någon förklara vad detta betyder i samband med gpg? Vad är poängen med gpg-agent?

Jag har för närvarande GPG 1.4.

  1. Hur vet jag om agenten kör? Jag vet faktiskt inte ens om gpg-agent är installerat med GPG 1.4-paketet.
  2. Hur kan jag starta det om det inte körs?
  3. Hur kan jag stoppa det, om det körs?

Svar

Gpg-agent är ett program som körs i bakgrunden (en daemon ) och lagrar hemliga GPG-nycklar i minnet. När en GPG-process behöver nyckeln kontaktar den det körande gpg-agentprogrammet genom ett -uttag och begär nyckeln. Om agentprocessen har nyckeln ger den den till gpg. Om den inte gör det försöker den att ladda den krypterade nyckeln från din nyckelring och uppmanar dig om nyckelns lösenfras. När agenten har fått den dekrypterade nyckeln skickas den till gpg-processen. Förutom GPG-nycklar kan Gpg-agent på samma sätt lagra SSH-nycklar och ge dem till SSH-processer, som ssh-agent program som kommer med SSH.

Huvudpoängen med att använda en nyckelagent är så att du behöver inte skriva din lösenfras varje gång du använder din nyckel. Agenten håller nyckeln i minnet från tid till annan. GPG själv kan inte göra det eftersom processen avslutas när den har gjort sitt jobb.

En annan sak som en nyckelagent kan göra är att låta GPG köras på en fjärrmaskin för att få nycklar i den lokala agenten ( som kan ladda dem från en lokal fil och be om din lösenfras). Gpg-agent kan inte göra det ännu, det är en planerad funktion . SSH har haft agentöverföring under mycket lång tid. (Detta är en anledning att inte använd gpg-agent för SSH-nycklar.)

GPG 1.x eller 2.0.x vet att agenten kör eftersom variabeln GPG_AGENT_INFO är inställd. innehåller platsen för uttaget för att kommunicera med agenten såväl som agentens process-ID. GPG 2.1 placerar alltid agentuttaget i ~/.gnupg. GPG 2.x startar alltid en agent process om en inte körs.

Du kan starta agenten helt enkelt genom att köra gpg-agent. Om du vill behålla en agentprocess som en del av din session kan du ersätta anropet av din session manager med gpg-agent my-session-manager; vissa distributioner ställer in detta automatiskt. GPG startar agenten automatiskt och GPG 2.1 kommer dessutom att hitta en agent som körs utan att behöva en miljövariabel, så du behöver inte starta den så här om du inte använder en äldre version av GPG eller använder agenten för att lagra andra typer av nycklar som SSH.

Du kan skicka agenten kommandon med gpg-connect-agent skalkommando. Skicka kill kommando döda agentprocessen (eller skicka en signal).

Gpg-agent skickas med GPG själv. Vissa distributioner paketerar det separat.

Kommentarer

  • " När en GPG-process behöver nyckeln, kontaktar den det körande gpg-agentprogrammet genom ett uttag och begär nyckeln. Om agentprocessen har nyckeln, det ger det till gpg. " Något missvisande. Agenten tillhandahåller inte en nyckel till klientprocessen. Istället är den perfekt orms åtgärder med hjälp av nyckeln, på uppdrag av klientprocessen. (Klienten ger agenten något att signera, kryptera eller dekryptera, och agenten gör det.) När du använder en agent får din SSH- och GPG-klientprogramvara aldrig tillgång till den faktiska nyckeln.
  • " Gpg-agent kan ' inte göra detta ännu, det är en planerad funktion. SSH har haft agentöverföring under mycket lång tid. (Detta är en anledning att inte använda gpg-agent för SSH-nycklar.) " Inte riktigt sant. gpg-agent fungerar bra med SSH agent vidarebefordran. Jag använder det varje dag. SSH-klienten hanterar vidarebefordran, gpg-agent är inte riktigt inblandad i det. Det som inte stöds är att GPG själv ska prata med en agent på distans.

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *