Dear Maintainer,

Since the upgrade to the newest gnupg-agent I had the problem that
gnupg-agent just refused any ssh agent work with a simple

sign_and_send_pubkey: signing failed: agent refused operation

which isn't all that helpful a message. I always had gnupg-agent
configured for the ssh-agent support and never run an ssh-agent
directly, which, until the upgrade, worked nicely.

Finally had time to look what broke in gnupg-agent - and it seems the
way its started now (or its now default way of working) is kinda stupid
compared to the past.

Past: An Xsession.d script that just had

$GPGAGENT --daemon --sh --enable-ssh-support --write-env-file=$PID_FILE $STARTUP

and whenever needed (my shell startup scripts) I fetched the agent vars
from that file. Works.

Now: "gpg agent started by systemd foo" for whatever reason. And the
script only exporting the SSH_AUTH_SOCK var.

The Now: is broken: It leaves people without a working ssh key agent. As
systemd starts it on whatever tty (maybe none). I finally found

$ gpg-connect-agent updatestartuptty /bye

somewhere in the manpage, and if I run that, ssh functionality is back.

I wonder if that shouldn't be run automagically at the time
SSH_AUTH_SOCK is exported. Its highly annoying and IMO a regression to
the past, if one has to manually do something to get ssh support running
in the agent.

Just upgraded from Jessie to Stretch, same issue.

This used to just work
$ eval $(gpg-agent --enable-ssh-support)


But ssh connections now fail miserably.

I'm offered the ssh key pinentry popup, and then:
I also tried to kill all that dbus-* things before retrying.
I was provided with the curl-based pinentry popup but failed the same way.


ssh-agent and/or hardcoding IdentityFile still works (hopefully)

I also noticed that running gpg 2.1 $(gpg-agent --enable-ssh-support)
automatically provides two of my keys. ssh-add -D does not seem to
remove them from the (gpg)-agent.
I guess those are the only two which were inside my agent at the time
gpg 2.1 migrated them inside ~/.gnupg/private-keys-v1.d/

This may or may not be related to the issue.


NB: I don't use systemd

On Tue, 20 Jun 2017 07:09, raphael.droz@gmail.com said:

Please don't do that anymore.

  SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"
  export SSH_AUTH_SOCK

is the way to go.

Right.  gpg-agent takes a copy of the key and stored it in its own DB.


Shalom-Salam,

   Werner

thanks for tip

good to know




But still, that's does not explain why my key (a password-less ssh-key
in this case) is refused by the agent:

Could the "agent" give me the *reason* why it didn't "want to sign"?
Any debugging/more verbose system here?

Running the agent --debug 4096 --debug-level guru --daemon --min-passphrase-len 0

$ ssh my-vm

gpg-agent[29336]: ssh handler 0x------------ for fd 8 started
gpg-agent[29336]: ssh request handler for request_identities (11) started
gpg-agent[29336]: ssh request handler for request_identities (11) ready
gpg-agent[29336]: ssh request handler for sign_request (13) started
gpg-agent[29336]: DBG: agent_get_cache '4B9XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXA' (mode 4) ...
gpg-agent[29336]: DBG: ... miss
gpg-agent[29336]: starting a new PIN Entry
gpg-agent[29336]: DBG: connection to PIN entry established
** Message: Remote error from secret service: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets was not provided by any .service files
Failed to lookup password for key s/4B9XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXA with secret service: The name org.freedesktop.secrets was not provided by any .service files
#### here ssh key PINentry popup => just enter (no passphrase) ####
gpg-agent[29336]: DBG: error calling pinentry: No passphrase given <GPG Agent>
gpg-agent[29336]: failed to unprotect the secret key: No passphrase given
gpg-agent[29336]: failed to read the secret key


I guess there may be something "special" against passphrase-less ssh keys, but
couldn't find any documentation/hints about this.

Hi,

$work imposed using a yubikey on me for ssh auth. After a long painful
search on how to disable the gnome-keyring on mate, I finally had the
same issue as Ganneff, and it took me another long painful web search to
find out how to fix. So I also have to do:

gpg-connect-agent updatestartuptty /bye

to get the gpg-agent to prompt for the yubikey pin to fetch the key. I
would very much like to find a fix for this, typing it on each new
session is very annoying. I'm guessing this isn't the fault of
gnupg-agent, but whoever is starting it using the --supervised option. A
quick ps auxf shows:

 /lib/systemd/systemd --user
  \_ (sd-pam)
  \_ /usr/bin/gpg-agent --supervised
      \_ scdaemon --multi-server

and pstree output is:

systemd─┬
        ├─systemd─┬─(sd-pam)
        │         └─gpg-agent───scdaemon───2*[{pipe-connection}]

so really, it looks like systemd is the badly configured thing here.

Cheers,

Thomas Goirand (zigo)

I don't see how systemd is "badly configured" -- the user service starts
up gpg-agent the first time it's needed.

gpg-agent itself invokes pinentry in order to talk to the user, so
pinentry needs to know some sort of environment information.

if you use pinentry-gnome3 (which is the preferred graphical pinentry)
it just needs to know the $DBUS_SESSION_BUS_ADDRESS, which should be
already available because the bus is already available at the time the
service is launched.  This will work whether you're running Wayland or
X11.

if you use pinentry-gtk2 or pinentry-qt within an X11 session, then
gpg-agent needs to know $DISPLAY and $XAUTHORITY so it can launch
pinentry.  These variables should be set into the systemd user service
activation environment when you log into a graphical session.  (i expect
"dbus-update-activation-environment --systemd DISPLAY XAUTHORITY" to be
invoked by however you start your X session -- if it's not happening,
that'd be good to know)

so as long as you don't try to use gpg-agent (either as ssh-agent or as
gpg-agent, or by explicitly "systemctl --user start gpg-agent.service")
before you've logged into your graphical user session, when gpg-agent is
launched, it will already know how to prompt you for a password for ssh,
and you shouldn't need to manually run workarounds like:

   gpg-connect-agent updatestartuptty /bye

If you can tell me how you start up your graphical session, maybe we can
track down the problem further.

Regards,

Cheers,

I've been having the same issue, where I'm getting this error when ssh'ing
into just about anything:

sign_and_send_pubkey: signing failed: agent refused operation

I do indeed startup my graphical session in a non-standard way (for
unrelated reasons):

0. systemd is set to a text startup target.
1. I login to a tty text console.
2. I run startx

It may be worth noting that after my DE (Budgie) has started, I'm usually
prompted to enter my password to unlock the login keychain.

Like others in this thread have mentioned, running the following command
seems to fix everything until I shut down:

$ gpg-connect-agent updatestartuptty /bye

Some system info:
$ uname -a
Linux dawnrose 4.18.0-1-amd64 #1 SMP Debian 4.18.8-1 (2018-09-18) x86_64
GNU/Linux

Hope this can help!

Regards,
Sofus Rose

I use this same workflow to start X11, and i don't have the problems
described.

what version of pinentry are you using?  do you have dbus-user-session
installed?

Regards,