Quoting Peter Lebbing (pe...@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
pgp5rNQ_xQ0V5.pgp
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
