Control: retitle 830658 gpg-agent: cannot talk to libsecret when used as ssh-agent and not started from the same session Control: tags 830658 + help upstream
Hi Brian-- On Sat 2016-07-09 18:58:43 -0400, brian m. carlson wrote: > The recommended way to use gpg-agent, according to README.Debian, is to > use systemd to start it automatically in the session. However, when > doing that, the agent does not inherit $DISPLAY. This prevents dbus, > and hence the libsecret integration in pinentry-gnome3, from working. > Since my passphrases are stored in my desktop's keyring integration, I > can't use my SSH keys: > > genre ok % ssh -oGSSAPIAuthentication=no castro > sign_and_send_pubkey: signing failed: agent refused operation > sign_and_send_pubkey: signing failed: agent refused operation > Permission denied (publickey,gssapi-keyex,gssapi-with-mic). > > A dump of the environment from such a gpg-agent process follows: > > HOME=/home/bmc\0LANG=en_US.UTF-8\0LOGNAME=bmc\0PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin\0SHELL=/bin/zsh\0TEMP=/tmp/user/1000\0TEMPDIR=/tmp/user/1000\0TMP=/tmp/user/1000\0TMPDIR=/tmp/user/1000\0USER=bmc\0XDG_RUNTIME_DIR=/run/user/1000\0MANAGERPID=2813\0 > > As you'll notice, it's lacking the most rudimentary X environment > variables. Thanks for this report (and sorry for the delay in response). This isn't a problem for the normal uses of gpg-agent (whether started in-session, via systemd, or even in a separate session), because gpg knows to send gpg-agent X11 and dbus session credentials on each use. It's a problem when gpg-agent is used as ssh-agent, because the ssh-agent protocol doesn't have any way to transmit these configuration preferences. This isn't just true for systemd-managed services, it's also true for a gpg-agent used across concurrent sessions (i.e. started in session A and then accessed from session B). So i'm not sure what the right approach is here; there's something of an impedence mismatch between OpenSSH's agent and GnuPG's agent, and having one pretend to be the other ends up with this sort of friction. By "impedence mismatch" i mean things like the following: * ssh-agent expects to be run ephemerally, with basically no access to the filesystem other than to launch ssh-askpass when needed, and gets its keys after each initialization by explicit handoff from the user. gpg-agent expects to read and manage its ~/.gnupg/private-keys-v1.d directory (where its secret key material is stored) and spawns scdaemon (if needed/installed) in addition to spawning pinentry. * ssh-agent is configured at process initialization about how and where to prompt for confirmation, and is configured at key-load about whether to prompt for the use of a given key. gpg-agent is configured at *use* time about how and where and whether to prompt for the use of a given key. Their associated non-daemonized tools (at least gpg and ssh) make some assumptions about these patterns. I'd welcome help in resolving this, but i'm not sure what the right thing to do is. --dkg
signature.asc
Description: PGP signature