On Sun 2017-01-15 11:35:59 -0500, Dominik George wrote:
>> Suddenly, using gpg-agent as ssh-agent with authentication subkeys
>> stopped working:
>>
>> sign_and_send_pubkey: signing failed: agent refused operation
>>
>> I can, however, still see my authentication subkeys in ssh-add -l:
>>
>> % ssh-add -l
>> 4096 SHA256:VCiRCk+EswSfauAe4hYWweglX6WqsIrtU08PGr7LL38 (none) (RSA)
>> 256 SHA256:SqObMOMaC5eckW3g9nvbOnQljUjjq8Hez5U0TcQqIwM (none) (ED25519)
>
> I found out this only happens when using the systemd user service.
> Disabling it and manually starting the agent works.
Do you have the dbus-user-session package installed? What pinentry are
you using?
Can you try terminating your manually-launched agent, re-enabling and
restarting the systemd user service, and then telling gpg-agent to
update its "startuptty" ?
gpg-connect-agent killagent /bye
systemctl --user enable --now 'gpg-agent*.socket'
gpg-connect-agent updatestartuptty /bye
then try using gpg-agent for ssh-agent again. does it work?
if so, then the issue has to do with the interaction between pinentry
and the systemd user services, and the fact that the ssh-agent protocol
doesn't have a way for a client to provide any hints or feedback to the
ssh-agent daemon about how to contact the user.
This impedance mismatch between ssh-agent and gpg-agent makes it
difficult for gpg-agent to know how to prompt the user by default. But
if you're using pinentry-gnome3 and dbus-user-session then the agent
will just know automatically how to prompt the user, because the user
services will know to use the same dbus session that pinentry-gnome3
uses to provide feedback to the user.
hth,
--dkg