GnuPGv2 & 'pinentry' on Linux w/ remote access
ssmeenk at freshdot.net
Thu Mar 30 22:41:12 CEST 2017
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.
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, 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
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
> > 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.
| 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
Size: 819 bytes
Desc: not available
More information about the Gnupg-users