Home / server / Questions / 755883
In Process
Steve Bonds
Asked: 2016-02-13 10:47:04 +0800 CST

RHEL6 and GPG 2.0.14: What is a working keyserver config with proxy?

  • 772

The documented solution doesn't seem to actually work. The documented solution:

In ~/.gnupg/gpg.conf change to use an HTTP keyserver and honor the environment variable http_proxy. The proxy I'm using is a special proxy that requires no authentication other than source IP. Yay!

keyserver http://http-keys.gnupg.net
keyserver-options honor-http-proxy verbose

Check my environment:

$ echo $http_proxy
http://proxy.name.com:8080

Check the proxy via other means:

$ telnet proxy.name.com 8080
Connected to proxy.name.com.
Escape character is '^]'.
^]
telnet> close
Connection closed.

strace -f gpg --recv-keys 0xABCDEF shows that it's ignoring the proxy and unsuccessfully trying to connect directly.

Any ideas?

redhat

1 Answers

  1. Yes! I found the magical combination of everything to get this working. I'll document it here so that Future Me (and anyone else) can find some potentially useful info about getting GPG working behind a corporate firewall and associated proxies.

    Issue 1: Not hitting the proxy at all

    Export your environment veriables. Yeah, that was a rookie mistake. Whoops.

    Issue 2: gpgkeys: http fetch error 60

    HTTP-to-HTTPS redirects. This could possibly also have been solved by manually adding the private CA data into my host config. I'm not a fan of that for a number of reasons centering around "Who do you trust?" and "What can they do with that trust?" By using a known untrusted HTTP connection I make it clear how much I trust that connection.

    Using the proper SKS server with HTTP gave me this not so useful result:

    $ gpg --verbose --keyserver=http://na.pool.sks-keyservers.net --keyserver-options=debug --recv-keys 0x1234567
... lots of nice debug data showing that all the connections are working great ...
gpgkeys: no key data found for http://na.pool.sks-keyservers.net/

    Issue 3: No Key Data Found

    Google led me to this docker issue where they had a very similar problem. The SKS pool contains a number of servers that may not all respond on the same ports. They suggested using http://p80.pool.sks-keyservers.net/

    $ gpg --verbose --keyserver=http://p80.pool.sks-keyservers.net --keyserver-options=debug --recv-keys 0x1234567
... connections still working fine via proxy ...
gpgkeys: no key data found for http://p80.pool.sks-keyservers.net/

    It looks like using the HTTP protocol on the p80 pool doesn't lead to something that can actually search for key data. Try using the HKP protocol:

    $ gpg --verbose --keyserver=hkp://p80.pool.sks-keyservers.net --keyserver-options=debug --recv-keys 0x1234567
... connection shows the proxy hangs connecting to port 11371 ...

    Ah, OK. I guess my special proxy can't get out to any old port like it used to. I'll have to fix that later... In the meantime, try HKP over TCP port 80:

    $ gpg --verbose --keyserver=hkp://p80.pool.sks-keyservers.net:80 --keyserver-options=debug --recv-keys
... connection shows an HTTP GET
GET http://p80.pool.sks-keyservers.net:80/pks/lookup?op=get&options=mr&search=0x1234567 HTTP/1.1
Host: p80.pool.sks-keyservers.net
...
gpg: pub  1024D/1234567

    Success! HKP over TCP port 80 worked!

    I got a key! Fix my config to use this working config by default:

    $ vi ~/.gnupg/gpg.conf
keyserver hkp://p80.pool.sks-keyservers.net:80
    • 0