Как обойти заблокированный исходящий порт hkp для ключей apt

Я использую Ubuntu 9.10, и мне нужно добавить несколько подходящих репозиториев. К сожалению, я получаю такие сообщения при запуске sudo apt-get update:

W: GPG error: http://ppa.launchpad.net karmic Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 5A9BF3BB4E5E17B5
W: GPG error: http://ppa.launchpad.net karmic Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 1DABDBB4CEC06767

Итак, мне нужно установить ключи для этих репозиториев. Под 9.10 у нас теперь есть возможность сделать это:

sudo add-apt-repository ppa:nvidia-vdpau/ppa

Посмотрите эту справочную статью по Ubuntu для подробностей.

Это здорово, за исключением того, что я запускаю это на рабочей станции за брандмауэром, который блокирует исходящие соединения практически со всеми портами, кроме тех, которые требуются секретарям под управлением Windows и IE.

Здесь речь идет о службе hkp, порт 11371.

Похоже, есть способы вручную загрузить ключи и установить их на связку ключей apt. Может даже быть способ использовать add-apt-repository или wget или что-то еще, чтобы загрузить ключ с альтернативного сервера, сделав его доступным через порт 80.

Тем не менее, я еще не нашел краткий набор шагов для этого. То, что я ищу, это:

1. Как найти открытый ключ для apt-пакета (рекомендации для ресурсов, у которых они есть, и / или советы по поиску. Поиск ключевого хеша пока не кажется таким уж эффективным).
2. Как получить ключ (это можно сделать автоматически с помощью gpg или add-apt-repository?)
3. Как добавить ключ в связку ключей apt

Заранее спасибо.

Это было исправлено в следующей версии Ubuntu для Natty: https://launchpad.net/ubuntu/natty/+source/software-properties/0.78.1

Те, кто использует более старую версию, должны отредактировать ppa.py:

sudo gedit /usr/lib/python2.6/dist-packages/softwareproperties/ppa.py

Где это говорит:

keyserver.ubuntu.com

изменить на:

hkp://keyserver.ubuntu.com:80

Сохраните, выйдите, тогда, надеюсь, вы готовы.

sudo apt-key adv --keyserver keyserver.ubuntu.com --keyserver-options http-proxy=http://proxy:port --recv-keys KEYID

Вот один из обходных путей, который я использовал:

Я вошел на сервер Linux в свободном мире за пределами нашего корпоративного брандмауэра и сделал это:

gpg --keyserver keyserver.ubuntu.com --recv 1DABDBB4CEC06767 && gpg --export --armor 1DABDBB4CEC06767

Затем на своей рабочей станции я запустил это и вставил вывод из вышеуказанной команды (открытый ключ) в стандартный ввод, а затем control-D:

sudo apt-key add -

Тогда я смог бежать sudo apt-get updateбез проблем.

Я все еще думаю, что должен быть лучший способ, в идеале, то, что я мог бы написать.

У меня есть другой обходной путь, который может быть полезен, если вы не можете найти другой сервер Linux вне вашей сети в качестве прокси. Просто отправьте электронное письмо по адресу "pgp-public-keys@pgp.mit.edu" как "get 0x1DABDBB4CEC06767". Но вы, вероятно, все еще не можете написать простой скрипт для автоматизации этого.

Вы можете перейти на веб-сайт сервера ключей, например, http://wwwkeys.eu.pgp.net/ Поиск ключевой подписи (необходимо добавить 0x к шестнадцатеричной подписи), то есть 0x1DABDBB4CEC06767.

Нажмите на ссылку, которую вы, вероятно, получите, и вставьте текст в файл на компьютере, т.е.

cat > <filename>

[PASTE]

[Ctrl-C]

затем

apt-key add <filename>

Это работало хорошо для меня; похоже мой рабочий прокси блокирует много "нестандартных" портов.

Я нашел аккуратный способ сделать это с помощью одной команды через порт 80, который всегда открыт для трафика www.

http://gurrier.wordpress.com/2010/10/02/downlolading-repo-keys-from-behind-a-corporate-firewall/

Простое решение:

sudo add-apt-repository --keyserver hkps://keyserver.ubuntu.com:443 some_ppa

Защищенный https (исходящий 443) не будет заблокирован брандмауэром.

Я просто использую ssh для перенаправления порта на внешний хост, а затем запускаю apt-add-repoкоманду.

ssh -fqTnN -D 11371 <user@host>

У меня была такая же проблема с gpg. Обходной путь с добавлением порта к имени сервера работал путем редактирования моего ~/.gnupg/gpg.confфайла. Тем не менее, я все еще собираюсь попросить нашего системного администратора открыть исходящий порт 11371, поэтому мне не нужно беспокоиться об этом снова.