2

I'm having some trouble getting gpg (actually pass which uses gpg in the background) to work inside of tmux and a Yubikey Neo. When attempting to decrypt a file or sign something using gpg I get the following:

$ gpg -d test.gpg gpg: sending command `SCD PKDECRYPT' to agent failed: ec=5.99 gpg: public key decryption failed: general error gpg: decryption failed: secret key not available

This is only inside of tmux, if I attempt to run the same command in a normal zsh session directly in gnome-terminal it just works:

gpg -d test.gpg helloworld

pinentry will pop up, ask me for the PIN to unlock the Yubikey and proceed to decrypt the file.

I think I narrowed the problem down to pinentry not being able to spawn. Setting the log level of the gpg-agent I get the following: 

gpg-agent[906]: DBG: chan_6 <- INQUIRE NEEDPIN ||Please enter the PIN gpg-agent[906]: starting a new PIN Entry gpg-agent[906]: DBG: chan_7 <- OK Pleased to meet you, process 906 gpg-agent[906]: DBG: connection to PIN entry established ... options removed ... gpg-agent[906]: DBG: chan_7 -> GETINFO pid gpg-agent[906]: DBG: chan_7 <- D 13381 gpg-agent[906]: DBG: chan_7 <- OK gpg-agent[906]: DBG: chan_7 -> SETKEYINFO --clear gpg-agent[906]: DBG: chan_7 <- OK gpg-agent[906]: DBG: chan_7 -> SETDESC Please enter the PIN gpg-agent[906]: DBG: chan_7 <- OK gpg-agent[906]: DBG: chan_7 -> SETPROMPT PIN gpg-agent[906]: DBG: chan_7 <- OK gpg-agent[906]: DBG: chan_7 -> [[Confidential data not shown]] gpg-agent[906]: DBG: chan_7 <- [[Confidential data not shown]] gpg-agent[906]: DBG: error calling pinentry: Operation cancelled <Pinentry> gpg-agent[906]: DBG: chan_7 -> BYE gpg-agent[906]: DBG: chan_6 -> CAN gpg-agent[906]: DBG: chan_6 <- ERR 100663573 IPC call has been cancelled <SCD> gpg-agent[906]: DBG: chan_5 -> ERR 83886179 Operation cancelled <Pinentry>

Nothing suspicious jumps out at me, except a few OPTION statements that apparently aren't handled by pinentry but I get the same when calling from gnome-terminal.

Setting the $DISPLAY variable also doesn't help, the error is identical.

Am I missing something? Is there some other variable I need to set? And why doesn't this fall back to pinentry-ncurses if it can't open a graphical one?

Improve this question
6
  • Does gpg-connect-agent UPDATESTARTUPTTY /bye help? Commented Oct 7, 2017 at 19:38
  • Sadly no change, it replies with OK but subsequent calls to gpg will error out like previously. I also tried setting the tty manually with export GPG_TTY="$(tty)" without any change. Commented Oct 8, 2017 at 13:26
  • You could trace the running gpg-agent with strace -f -o dump.strace -p $PID once for both terminals each and then have a look at the differences. Commented Oct 8, 2017 at 13:36
  • That's a really good tip, thanks Hauke. I was able to trace both processes side by side and they differ when attempting to talk to dbus. The tmux gpg fails to connect for some reason. If I set the DBUS_SESSION_BUS_ADDRESS variable in tmuxas well it suddenly works. Commented Oct 8, 2017 at 13:57
  • Ok, so this seems to be fixed by adding set-option -g update-environment 'DBUS_SESSION_BUS_ADDRESS' to my .tmux.conf. So in the end it was just a stale dbus environment variable... Thanks for the help Hauke, if you'd like to write a short response I'll gladly accept it ^^ Commented Oct 8, 2017 at 14:07

1 Answer 1

Reset to default
7

The problem was that (for some reason) gpg tries to use dbus but within tmux the environment variable DBUS_SESSION_BUS_ADDRESS was outdated.

This can be fixed with

set-option -g update-environment 'DBUS_SESSION_BUS_ADDRESS'

in .tmux.conf.

Improve this answer
1
  • I'm not sure why, but this didn't work for me by just executing :set-option ... from my existing tmux session -- I had to add this to my .tmux.conf file and restart tmux (like you say) Commented Jun 18, 2019 at 14:54

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.