sitter at kde.org
Mon Aug 8 15:07:41 UTC 2016
On Sun, Aug 7, 2016 at 9:01 PM, David Faure <faure at kde.org> wrote:
> On mercredi 15 juin 2016 12:53:23 CEST Andre Heinecke wrote:
>> I'm using agent-forwarding through socat for that reason:
>> Here is an example how I connect to <myserver>. The last command is
>> executed after ssh on the server.
>> (while true; do socat TCP-LISTEN:16668,bind=127.0.0.1
>> UNIX-CONNECT:/home/aheinecke/.gnupg/S.gpg-agent.extra; done) & ssh
>> -R16668:localhost:16668 <myserver>
>> (while true; do socat
>> TCP4:localhost:16668; done) &
> So, I lost a few more hours on this, and still no go.
> $ (while true; do socat TCP-LISTEN:16668,bind=127.0.0.1 UNIX-CONNECT:
> $HOME/.gnupg/S.gpg-agent-extra; done) &
> (my local config has "-extra", while yours has ".extra")
> $ ssh -R16668:localhost:16668 scripty at l10n.kde.org
> scripty at rosetta ~ $ (while true; do socat UNIX-LISTEN:$HOME/.gnupg/S.gpg-
> agent,unlink-close,unlink-early TCP4:localhost:16668; done) &
> All good until here, but:
> scripty at rosetta ~ $ gpg-connect-agent
> gpg-connect-agent: error sending standard options: Unknown error code
> scripty at rosetta ~ $ gpg2 --output /dev/null --sign -u 0x09B06E10 /dev/null
> gpg: skipped "0x09B06E10": No secret key
> The server has OpenSSH_6.0p1, gpg (GnuPG) 2.0.19 and socat 184.108.40.206-1.4.
So I read up on this a bit and the way I see it this won't ever fly
with gpg<2.1 because in earlier versions the signing would always hit
the keyring  file on-disk. So, this is actually a two part problem:
- you need an agent socket forward from localhost to remote (openssh
6.7+ or manual socat socket forward )
- keyring needs to be available on remote (gpg2.1+ to forward keyring
itself via agent socket)
That said, you *could* copy your secring to the server to bypass
problem number 2. Why the manual socat socket failed for you I am not
sure as it works fine for me. It might be that a tiny bit went wrong
along the way, the socat method is fairly fragile. At any rate, I
think copying secrings around is a bit daft so the socket forwarding
is really the less concerning problem here.
IMO options at this point are:
1. Move release tarballing from rosetta to a server/container with
gpg2.1 (ideally this would be an ephemeral server in the cloud to give
less targetted attack surface)
2. Use a joint key that lives on rosetta until rosetta migrates to a
system with gpg2.1 at which point the agent forwarding can be
3. Copy secrings (ugh) and use socat forwarded agent
I think option 2 would be perfectly acceptable as a stop-gap if you
need to stay on rosetta, after all, if one were to compromise the
server, one could poison the tarballs during creation and an off-site
signing key won't help much with that.
On a related note, we maybe should have a talk about not doing
tarballs on a general purpose server that isn't super hardened :P
* ssh(1), sshd(8): Add support for Unix domain socket forwarding.
A remote TCP port may be forwarded to a local Unix domain socket
and vice versa or both ends may be a Unix domain socket.
More information about the release-team