[HELP] pinentry-curses breaks SSH auth, but pinentry-mac works fine?

[Ryan Lue]

> However, I think many people work around this problem by a) using a
> graphical pinentry and b) using a single graphical session. As long as
> one also refrains from SSH'ing from a remote terminal, with the
> combination, you've circumvented the problem by just using the
> effectively singleton graphical session :-).

That solution has certainly occurred to me. There were two reasons I was
really angling to get this working purely in the terminal:

1) I keep my dotfiles synced between multiple machines, and so try my
   best to keep them platform-agnostic when I can. There are definitely
   times when I can use conditionals to get different behavior on
   different machines (like `if [ "$(uname)" = Darwin ]` in `.profile`),
   but I don't even know if it's possible to set up `gpg-agent.conf` to
   use `pinentry-mac` on one machine but `pinentry-gtk` on another.

2) I chanced upon this presentation from a 2015 conference where the
   presenter describes a setup for being able to ssh into a machine and
   use its private keys locally by forwarding the remote machine's
   gpg-agent socket to a local socket (slides 57–61 of 62):

   https://2015.rmll.info/IMG/pdf/an-advanced-introduction-to-gnupg.pdf

   and I imagine that just wouldn't work if you had graphical pinentry
   on the remote machine. I did also find another tip about using
   `PINENTRY_USER_DATA` to force pinentry-curses for SSH sessions, but
   I'd already burned so much time on this that I haven't been able to
   justify getting around to it again:

   https://gpgtools.tenderapp.com/kb/faq/enter-passphrase-with-pinentry-in-terminal-via-ssh-connection

   None of this was crucial, mind you; I was just trying to see what I
   could do with a new toy. -_-'

> That is a surprising characterization. Do they also think this of the
> GNOME and KDE SSH agents, to name two? I suspect those two are much more
> widely used, which might eliminate the qualification "unconventional",
> but that still begs, why "hack"?

There were a lot of strong opinions being thrown around that thread. I
suspect that a lot of people believe that taking an unconventional
approach to security is tantamount to opposing best practices.

In any case, thanks for all the insight!

—Ryan