PR to support console-based pinentry clients?

[tomeon]

I recently ran into an issue attempting to use console-based pinentry clients (pinentry-tty and pinentry-curses) with yubikey-agent. The details are in this issue comment in the gopasspw/gopass repo; in brief, the problem is that pinentry doesn't know the correct TTY to use for obtaining the PIN, defaults to using something that's not a TTY (its own stdin, which is a pipe set up by gopasspw/pinentry), and crashes:

$ ssh somehost
sign_and_send_pubkey: signing failed for ECDSA "YubiKey #99999999 PIV Slot 9a" from agent: agent refused operation
myuser@somehost: Permission denied (publickey).

With yubikey-agent showing:

2021/07/15 12:00:00 agent 13: pin prompt: unexpected response: YubiKey serial number: 99999999 (3 tries remaining)

Would you be willing to consider a PR introducing one or both of the following?:

• The ability to manually provide the PIN to a running yubikey-agent process (e.g., yubikey-agent -l /path/to/yubikey-agent.sock -enterpin) so that it could be cached for later use when an ssh client process comes calling. This looks analogous to the approach taken by ssh-agent's PKCS#11 applet support, which the README characterizes as poor UX. However, this approach has the advantage of making it easy to answer the question of which TTY pinentry should use: the TTY that ran yubikey-agent -enterpin.
• Something similar to gpg-agent's gpg-connect-agent updatestartuptty /bye command, which informs the running agent that it should use the TTY specified in the GPG_TTY environment variable as the TTY for for pinentry interactions. This would facilitate using an equivalent of this neat trick for ensuring that pinentry always runs on the same TTY as the relevant ssh client process.

Thanks!

[FiloSottile]

Hmm, I see the issue. yubikey-agent is kind of designed with the idea of being used with a global graphical pinentry.

I would like the complexity of dealing with TTYs to be outside yubikey-agent. Here's an idea: add to contrib/ a command that when invoked with -update updates the TTY, and when invoked otherwise runs the pinentry on that TTY. Then you can use that as the pinentry for yubikey-agent, which stays oblivious of how it all works.

[rHermes]

I'm being hit with the same problem. @tomeon how are you able to specify which pinentry program that should be invoked. This worked for me for multiple days, but this morning I got the same error message.

Note, I'm trying to use a graphical pinentry backend, but it appears no to be working

[supermarin]

Ran into this issue as well. Think the UX is suboptimal at the moment: there's no proper error message, and there's a need of maintaining gpg-agent conf even if you don't want to use gpg anymore.
age-plugin-yubikey handles PIN inputs in TTY, and experience is inconsistent between the two.
Think it might be a good time to revisit this decision.