Page MenuHome GnuPG

Terminal use case for gpg-agent and gpg-agent for ssh-agent feature
Open, NormalPublic


Situation is Debian systemd socket activation, and login to terminal (not using Desktop Graphical environment) and use gpg-agent as ssh-agent.

In the socket activation configuration, a user requires UPDATESTARTUPTTY to let gpg-agent knows about his TTY.
(This should be well explained in a document.)

  • If it doesn't have GPG_TTY, pinentry will hang (this should be detected?)
  • Once pinentry hangs, gpg-agent remains there, and next requests keep hanging

After login, a user needs to do:

gpg-connect-agent UPDATESTARTUPTTY /bye

Event Timeline

werner added a subscriber: werner.

gpg-agent has a pinentry caling timeout - doesn't that trigger?
In any case we agreed that Debian takes care of systemd support because that is not an upstream supported configuration.

gniibe triaged this task as Normal priority.

This entry was created based on the conversation at #gnupg channel.
I can't reproduce keep hanging.
I confirmed that pinentry vanished (perhaps, because of timeout).

gniibe updated the task description. (Show Details)

This doesn't sound systemd-specific to me, fwiw, though i don't understand how to reproduce the problem from the given description here.

if there are two textual connections to a given user account on the machine (e.g. two ssh connections), then the second one will likely run into the same problem as that described here, even if systemd is not in use.

If you can describe a clearer way to reproduce, i'm happy to help figure it out, though.

Does gpgconf --reload gpg-agent trigger that command? that's the ExecReload setting in the systemd service unit I'm looking at.

trigger what command? i'm pretty sure gpgconf --reload gpg-agent does not trigger updatestartuptty. And it should not do so, afaict -- if you think it should, i'd be interested in hearing the rationale for it.