我们公司使用在 /etc/environment 和 apt.conf.d 中正确设置的过滤代理,可以
通过 http 和 https 进行常规互联网访问,但如果我尝试从 keyserver.ubuntu.com 导入 pgp 密钥,则会失败。
例子:
$ apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 36A1D7869245C8950F966E92D8576A8BA88D21E9
gpg: requesting key A88D21E9 from hkp server keyserver.ubuntu.com
gpgkeys: key 36A1D7869245C8950F966E92D8576A8BA88D21E9 can't be retrieved
gpg: no valid OpenPGP data found
支持人员表示,他们发现密钥服务器不接受 HTTP/1.0 标头(见下文),尽管 HTTP/1.0 是有效请求。
所以他们说问题出在密钥服务器方面,他们不愿意采取任何措施。
我无法判断这是否属实,我也找不到任何 Ubuntu 密钥服务器的联系人来获取声明,所以我陷入了困境。
从 zscaler 代理支持获得的跟踪:
GET /pks/lookup?op=get&options=mr&search=0x36A1D7869245C8950F966E92D8576A8BA88D21E9 HTTP/1.0
Cache-Control: no-cache
Pragma: no-cache
Connection: Close
X-Forwarded-For: 62.180.121.22*
虽然从 RFC 的角度来看此请求有效,但服务器拒绝了该请求并显示400 Bad Request
错误
HTTP/1.0 400 Bad Request
Server: squid/3.1.19
Mime-Version: 1.0
Date: Mon, 09 Mar 2015 09:39:47 GMT
Content-Type: text/html
Content-Length: 3346
X-Squid-Error: ERR_INVALID_URL 0
Vary: Accept-Language
Content-Language: en
X-Cache: MISS from cassava.canonical.com
X-Cache-Lookup: NONE from cassava.canonical.com:11371
Via: 1.0 cassava.canonical.com (squid/3.1.19)
Connection: close*
答案1
由于这是一篇旧帖子,我将简短回答。apt-key 命令选项“--recv-keys”使用非 HTTP/HTTPS 端口来访问密钥服务器。因此,它可能在防火墙环境中失败。
apt-key --recv-keys 36A1D78 // may fail with firewall
解决方案是将实际的 GPG 密钥手动复制到文本文件中,例如 key.txt,然后像这样使用 apt-key
sudo apt-key add key.txt
这会将二进制形式的 ascii 密钥添加到 /etc/apt/trusted.gpg 文件中。您可以通过以下方式检查它是否存在:
apt-key 列表|更多
您应该会看到列出的密钥“36A1D78”。要获取“实际 GPG”密钥,请转到 PPA 的 launchpad.net 网站并单击“签名密钥”链接,直到您进入包含 ASCII 格式密钥的页面。