Задокументированное решение, похоже, не работает. Документированное решение:
В ~/.gnupg/gpg.conf изменить, чтобы использовать сервер ключей HTTP и соблюдать переменную среды http_proxy. Я использую прокси-сервер, который не требует никакой аутентификации, кроме исходного IP. Ура!
keyserver http://http-keys.gnupg.net
keyserver-options honor-http-proxy verbose
Проверьте мою среду:
$ echo $http_proxy
http://proxy.name.com:8080
Проверьте прокси другими способами:
$ telnet proxy.name.com 8080
Connected to proxy.name.com.
Escape character is '^]'.
^]
telnet> close
Connection closed.
strace -f gpg --recv-keys 0xABCDEF показывает, что он игнорирует прокси и безуспешно пытается подключиться напрямую.
Любые идеи?
Да! Я нашел волшебную комбинацию всего, чтобы это работало. Я задокументирую это здесь, чтобы Future Me (и все остальные) могли найти потенциально полезную информацию о том, как заставить GPG работать за корпоративным брандмауэром и соответствующими прокси.
Экспортируйте вашу среду veriables. Да, это была ошибка новичка. Упс.
Перенаправления с HTTP на HTTPS. Возможно, это также можно было решить, добавив вручную данные частного CA в конфигурацию моего хоста. Я не фанат этого по ряду причин, связанных с вопросом: "Кому вы доверяете?" и «Что они могут сделать с этим доверием?» Используя известное ненадежное HTTP-соединение, я проясняю, насколько я доверяю этому соединению.
Использование правильного сервера SKS с HTTP дало мне этот не очень полезный результат:
$ 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/
Google привел меня к эта проблема с докером, где у них была очень похожая проблема. Пул SKS содержит несколько серверов, которые могут не отвечать на одних и тех же портах. Они предложили использовать 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/
Похоже, что использование протокола HTTP в пуле p80 не приводит к чему-то, что действительно может искать ключевые данные. Попробуйте использовать протокол HKP:
$ gpg --verbose --keyserver=hkp://p80.pool.sks-keyservers.net --keyserver-options=debug --recv-keys 0x1234567
... connection shows the proxy hangs connecting to port 11371 ...
Ах хорошо. Думаю, мой специальный прокси не может подключиться к старому порту, как раньше. Мне придется исправить это позже ... А пока попробуйте HKP через TCP-порт 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
У меня есть ключ! Исправьте мою конфигурацию, чтобы использовать эту рабочую конфигурацию по умолчанию:
$ vi ~/.gnupg/gpg.conf
keyserver hkp://p80.pool.sks-keyservers.net:80