quick guide https://gist.github.com/apachelogger/4aa69ad0637feedb330b3fadc7adea3a
with openssh 6.7 and gpg 2.1 it really is this simple (do note that gpg2.1 needs to be on server and client!) On Mon, Sep 12, 2016 at 12:33 PM, Harald Sitter <[email protected]> wrote: > 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
