GnuPGv2 & 'pinentry' on Linux w/ remote access

[Sander Smeenk]

Quoting Peter Lebbing (peter at digitalbrains.com):

> > | GPG_TTY=$(tty)
> > | export GPG_TTY
> > | eval $(gpg-agent --daemon)
> This is the style for GnuPG 2.0, not for 2.1. 2.1 uses a standard
> socket location and the OpenPGP part of the agent will Just Work(tm).
> You still need something for the SSH part, and for GnuPG v1 if you
> want to have that use the agent.

Thanks for your detailed answer, Peter!

Indeed the pain seems to start with 'enable-ssh-support' and actually
using that interface. It all seems a bit cumbersome with the
updatestartuptty business, broken terminals and other foo.
Unfortunately.
It would have been nice if this actually worked well. ;-)

Currently i *don't* start a "session" gpg-agent on my work station, i
leave starting it to whatever needs it and then it keeps on running.
This works flawlessly it seems even when connecting remotely through SSH.
I only do terminal based GPG interaction...


> If you need the agent for GnuPG v1 [ .. ]

No, i've committed to 'upgrading' to v2 :-)


> Finally, there is the TTY issue. gpg will pass the TTY (or DISPLAY) it
> is running on to the agent, so the pinentry pops up on the TTY/DISPLAY
> where the invoking gpg was running. Unfortunately, SSH has no facility
> for that, so the pinentry pops up on the "startup TTY". When I'm using
> SSH from a terminal running on my graphical X session, it turns out
> just fine: pinentry-gtk-2 pops up on my X screen. When I'm connecting
> remotely, it goes wrong.

Now i read this, it makes sense that ssh isn't properly interfacing with
gpg-agent to make this operation seamless.

Has anyone dared submitting an API-patch to Theo yet? ;-))
 

> Personally before I SSH from a remote session[1], I run:
> gpg-connect-agent updatestartuptty /bye You could put that in a shell
> script with a shorter name...  As long as I don't forget to run the
> gpg-connect-agent command, it always works fine for me.

I tried putting that command in my bashrc but that was a bad idea when
running with enable-ssh-support. Perhaps one could alias 'ssh' (and
friends) to run the updatestartuptty command first...

Hm. Smells fish^Whacky.


> If you use a graphical pinentry and it needs to pop up on a text
> terminal instead, it will automatically fall back to the curses based
> pinentry.

I'm quite certain all my usage of GPG will be in text terminals, but
this is good advise not to mess with that setting and leave it to the
defaults. I believe i put that there when i was fighting with the
enable-ssh-support TTY-issue.


> > With this config, trying to decrypt a GPG-file, everything stalls
> > and undescriptive errors appear after staring at a blinking cursor
> > for quite some time.
> When using gpg?

Yes. But perhaps, considering the insights provided by your earlier
wisdom, gpg (pinentry) might have misbehaved because of the ssh-agent
TTY-issue. Set a broken 'updatestartuptty' and gpg will honour that too?

GPG (pinentry) works just fine when not using enable-ssh-support it seems.


> > Sometimes resulting in *'s being displayed while typing, or letters
> > disappearing from the input altogether.
> I think every other character goes to the terminal [ .. ]
> It's a great way to get half of your password in .bash_history if you just keep on typing.

Hahah. :)


-- 
| 1 1 was a racehorse, 2 2 was 1 2, 1 1 1 1 race 1 day, 2 2 1 1 2
| 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7  FBD6 F3A9 9442 20CC 6CD2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </pipermail/attachments/20170330/fa90ab87/attachment.sig>