On Sat, Sep 10, 2016 at 1:26 PM, David Faure <[email protected]> wrote: > On lundi 8 août 2016 17:07:41 CEST Harald Sitter wrote: >> 1. Move release tarballing from rosetta to a server/container with >> gpg2.1 > > So, now we are trying this. > > Partial success, ssh says > "remote forward success" > and running gpg-connect-agent on the server works > (and it triggers debug output in the ssh-forwarding terminal). > > However any gpg2 command on the server doesn't seem to use the agent. > --detach-sign leads to "No secret key" > --list-keys and --list-secret-keys show nothing. > > I added use-agent to ~/.gnupg/gpg.conf (but I think that's an outdated option > anyway), and I set default-key there, no improvement > ("gpg: all values passed to '--default-key' ignored", googling says this is a > consequence of "no secret key").
Documentation is fairly lackluster, but from poking around I'd say that you need to add your public key on the server's keyring. Specifically [1] talks about private keys coming out of the agent while public ones come out of the keyring, supposedly gpg would first check if it even has a public key though, and in fact that what it looks like with debugging. I set my agent into `debug-level guru`, reload, forward, when reloading from the remote via `gpg-connect-agent reloadagent /bye` I see it correctly hitting the agent. When using gpg2 on the remote to sign or encrypt I do not see it hitting the local agent UNTIL I add my public key. example: https://gist.github.com/apachelogger/1347ffe9508e0c5be163d05827a97844 So, assuming the socket forward works and `gpg-connect-agent reloadagent /bye` works from the remote, only three things come to mind that can be wrong: a) public key not available b) the remote server session actually has an agent running (which would be weird, but given gpg2 auto-starts an agent if it can't find a socket it's not impossible) c) no GUI pinentry is used. specifically when the agent would use curses pinentry it won't work since the prompt is on the local machine in whatever tty it was originally forked from (if any) this results in temporarily stuck gpg2 on remote though. On a related note gpg2 --list-secret-keys will not actually list the key UNLESS the public key is available. [1] https://www.gnupg.org/faq/whats-new-in-2.1.html#nosecring HS
