Wie kann ich dem ssh-agent mitteilen, dass er sich beenden soll?

[Mathias Bauer]

* Helmut Waitzmann schrieb am So, 14. Dez 2014, um 02:48 (+0100):

> Mathias Bauer <mbauer at mailbox.org> writes:
>
> > * Helmut Waitzmann schrieb am Fr, 12. Dez 2014, um 20:18 (+0100):
> >
> > hier läuft
> >   $ gpg-agent --version
> >   gpg-agent (GnuPG) 2.0.19
>
> Bei mir ist es
> $ gpg-agent --version
> gpg-agent (GnuPG) 2.0.14
>
> > Ein TERM beendet den Agenten; bei drei TERMs oder einem INT
> > geschieht das sofort (ohne Rücksicht auf Verluste).  Die
> > Prozessnummer ist Teil von GPG_AGENT_INFO:
> >   /path/to/socket/S.gpg-agent:12345:1
>
> [...]  und auch nicht, was geschieht, wenn im Socketnamen ein
> Doppelpunkt enthalten ist.

Was meinst Du damit?  Den Namen des Sockets, S.gpg-agent, kannst
Du nicht vorgeben und er enthält auch nie einen Doppelpunkt.

> Mein ssh-agent weigert sich, das Socket anzulegen, wenn ich ihm
> das Option „--use-standard-socket“ mitgebe und GNUPGHOME einen
> „:“ enthält.  Soweit also keine Gefahr für mehr als 2 „:“ in
> GPG_AGENT_INFO.  Nur das Handbuch schweigt halt dazu.

Ich ordne mal ein wenig:
- Du verwendest einen separaten SSH-Agenten und *nicht* gpg-agent
  mit der Option --enable-ssh-support.
- Was der SSH-Agent macht oder nicht, lassen wir jetzt erstmal
  außen vor.

Wo kommen bei Dir denn Doppelpunkte in Pfaden oder Namen vor?
Welches OS/Distribution verwendest Du denn?  Startet man den
gpg-agent mit der Option --use-standard-socket, erhält man

   GPG_AGENT_INFO=/home/you/.gnupg/S.gpg-agent:12345:1

Das kann man *nicht* machen, wenn das HOME-Verzeichnis per NFS
importiert wird, was auch so dokumentiert ist:

   This option may not be used if the home directory is mounted
   on a remote file system...

> > Das ganze Vorgehen ist abhängig davon, wie Deine Sessions
> > gestartet werden, ob Konsole und/oder X, ob mehrere parallel,
> > etc.
>
> Einen gpg-agent möchte ich bei jedem Einloggen zur Verfügung
> haben, egal, ob auf der Konsole oder mit X11.

Das funktioniert und ist auch kein Problem.  Starte einfach bei
jeder Anmeldung einen neuen Agenten.  Schwierig wird es in den
beiden folgenden Situationen:

- Es soll ein und derselbe Agenten benutzt werden.

- Für mehrere, auch parallel benutzte X- oder Konsole-Sessions
  soll der Agent der *ersten* gestarteten Session für alle
  anderen ebenfalls verwendet werden.

Da muss man ganz genau analysieren an welcher Stelle, X und
Konsole, der Agent jeweils gestartet wird, wo die
Environment-Variablen wirken, etc. und das Ganze dann
entsprechend modifizieren.  Du bist Dir im Klaren darüber, dass
das u. U. tiefgreifende Änderungen im (Linux-)System erfordert?
Wenn ja, kannst Du beide Probleme mit der Option --write-env-file
beheben.  Das wird sehr schnell sehr umfangreich werden...

Mein Rat: Beschränke Dich auf die Skripte des jeweiligen
Benutzers und lass die Finger von /etc/X11/Xsession.d/* - wenn Du
Linux verwendest.  Das geht und ist umfangreich genug.  Ich habe
eine solche Lösung hier am Laufen.

> Ich hätte nichts dagegen, wenn es machbar wäre, auf jedem
> Rechner, der das gemeinsame NFS‐HOME‐Verzeichnis nutzt, nur
> einen gpg-agent für alle Sessions zu nutzen.

Auf jedem Rechner jeweils pro Benutzer für alle Sessions jeweils
nur einen Agenten zu verwenden funktioniert.  NFS hat damit
nichts zu tun.

> Das hätte den Vorteil, dass ich diesen einen gpg-agent nicht
> beenden muss: Er soll ja sowieso für alle weitere Sessions
> (egal, ob augenblickliche oder zukünftige) verwendet werden.
> Das bedeutet aber, dass ich beim Einloggen nicht einfach einen
> gpg-agent starten kann, denn es könnte ja bereits einer laufen.

Ja.

> Deswegen kann dann der Fall eintreten (wenn doch noch kein
> gpg-agent läuft), dass gpg2 selber einen startet.  Weil ich
> dabei aber keine Möglichkeit habe, "${GPG_AGENT_INFO}" an
> andere bereits laufende Prozesse (etwa ein Mailerprogramm)
> weiterzugeben,

Doch, die hast Du, wenn Du früh genug in den Sessions eingreifst.

> müsste das Socket des von gpg2 gestarteten gpg-agents dann
> immer an derselben Stelle im Dateisystem zu finden sein,

Der Socket befindet sich immer auf dem jeweiligen Rechner in
/tmp, nicht irgendwo per NFS.  (Ausnahme: --use-standard-socket)
Du hast Recht, das Verzeichnis des Sockets ist nicht fix.  Hier
z. B. gerade

  /tmp/gpg-y5srdG/S.gpg-agent:12345:1

> ich müsste also in gpg-agents Konfigurationsdatei
> „use-standard-socket“ vermerken.  Das aber ist laut
> Dokumentation nicht erlaubt, wenn
> "${GNUPGHOME-"${HOME}/.gnupg"}" vom NFS kommt.

Genau, und das macht auch Sinn so.  Sockets bleiben lokal.

> Also bleibt wohl nur die Vorgehensweise „für jedes
> Login‐Session einen eigenen gpg-agent“: Weil dabei bei jedem
> Login in jedem Fall ein gpg-agent gestartet wird, kann die von
> ihm herausgegebene Umgebungsvariable GPG_AGENT_INFO einfach an
> alle weiteren Prozesse des Sessions vererbt werden und es
> entsteht auch nicht das Problem, dass gpg2 selber einen
> gpg-agent startet.

Entweder so (Du hast dann mehrere Agenten) oder Du prüfst beim
Start jeder Session, ob bereits ein Socket läuft und startetst
ggf. einen neuen mit der Option --write-env-file.

Wie schon oben angedeutet, ist diese Prüfung des springende
Punkt.  Dafür musst man an mehreren Stellen des Startprozeders
(Shell-Skripte!) eingreifen.  Das ist sehr umfangreich und etwas
kompliziert, funktioniert jedoch.

> Ich habe durch Ausprobieren festgestellt: Die mit dem Option
> „--write-env-file“ vom Agent erzeugte Umgebungsvariablen‐Datei
> wird weder geleert noch entfernt, wenn sich der Agent nach
> Empfang eines TERM‐Signals beendet.  Das Socket aber wird
> entfernt.
>
> Kann ich daran, ob das in "${GPG_AGENT_INFO%:*:*}" genannte
> Socket vorhanden ist, sehen, ob ein gpg-agent läuft?

Ja, mit zusätzlichen Prüfungen wie meiner letzten E-Mail erwähnt.
Die genügen für das XXL-Szenario (mehrere Sessions, parallel,
etc.) natürlich nicht.

> Dann könnte ich das als weiteres notwendiges Kriterium nutzen,
> ehe ich beim Ausloggen ein TERM‐Signal in Richtung gpg-agent
> schicke.  Aber auch hier gäbe es dasselbe Race‐Condition wie
> oben.

Ich beende hier weder unter X noch auf der Konsole den Agenten
automatisch.  Wenn man alle relevanten Möglichkeiten
ausfallsicher abdecken möchte, ist das Starten dieses einen
Agenten ausreichend umfangreich...

> Wird die vom Agent mit Option „--write-env-file“ erzeugte
> Umgebungsvariablen‐Datei von gpg2, gpg-connect-agent oder
> gpg-agent gelesen oder ist sie nur eine Alternative zu
>
> $ eval "$(gpg-agent --daemon)"

Diese Datei, deren Ort Du vorgibst, wird von niemandem gefunden
und daher auch nicht automatisch gelesen.  Du kannst sie selbst
z. B. in Startskripten des Benutzers für X- und Konsole-Sessions
verwenden.

Mathias

-- 
CAcert Assurer - See http://www.CAcert.org for details or ask me
GnuPG/OpenPGP: B100 5DC4 9686 BE64 87E9 0E22 44C3 983F A762 9DE8
-------------- n�chster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 760 bytes
Beschreibung: nicht verfügbar
URL         : </pipermail/attachments/20141214/7ae454fb/attachment.sig>