gpg: сбой приема сервера ключей: сервер указал сбой

Столкнулся с такой же проблемой в Ubuntu 18.04 с dirmngr 2.2.4. Я решил проверить свои настройки DNS и добавил свой локальный DNS-сервер «сервер имен 1.1.1.1» и «сервер имен 8.8.8.8» Google. Тогда это сработало.

Добавьте 0xперед клавишей, чтобы получилось 0xF88F6D313016330404F710FC9A2FD067A2E3EF7B.

Это и ответ GAD3R помогли мне решить эту проблему.

Эта проблема действительно была для меня, хотя ни одно из предложенных решений не работало для меня, пока я не нашел этот пост на Reddit. Я просто пошел и добавил эту строку в/etc/resolv.conf

nameserver 8.8.8.8 # Google dns

вы можете попробовать любой другой DNS и посмотреть, какой из них вам подходит.

Обычно, когда в вашей системе используется нестандартная конфигурация DNS, например, если вы используете dnsmasqили другую службу DNS, отличную от systemd-resolve, возможно, что dirmngr, используемый gpg, не работает. получите разрешенное имя для keyserver.ubuntu.com, затем вам нужно проверить программное обеспечение для разрешения имен.

В моем случае я установил dnsmasqдля разрешения имен на почтовом сервере Zimbra. В этом случае важно, чтобы вы не допустили, чтобы программное обеспечение resolvconfуправляло dnsmasq, это редактирование файла /etc/default/dnsmasqи раскомментирование этой строки :IGNORE_RESOLVCONF=yes. Затем вам нужно перезапустить dnsmasqи попытаться разрешить локальный DNS-сервер с помощью этой команды:

:~$ host -v keyserver.ubuntu.com 127.0.0.1

Если все в порядке, вы увидите что-то вроде этого:

Trying "keyserver.ubuntu.com"
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases: 

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13994
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;keyserver.ubuntu.com.      IN  A

;; ANSWER SECTION:
keyserver.ubuntu.com.   417 IN  A   162.213.33.8
keyserver.ubuntu.com.   417 IN  A   162.213.33.9

Received 70 bytes from 127.0.0.1#53 in 14 ms
Trying "keyserver.ubuntu.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33907
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;keyserver.ubuntu.com.      IN  AAAA

Received 38 bytes from 127.0.0.1#53 in 1 ms
Trying "keyserver.ubuntu.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45211
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;keyserver.ubuntu.com.      IN  MX

;; AUTHORITY SECTION:
ubuntu.com.     1748    IN  SOA ns1.canonical.com. hostmaster.canonical.com. 2018053167 10800 3600 604800 3600

Received 99 bytes from 127.0.0.1#53 in 16 ms

Даже если вы не используете какой-либо DNS-сервер, попробуйте спросить у systemd-resolve, может ли он разрешить URL-адрес с помощью этого:

:~$ host -v keyserver.ubuntu.com 127.0.0.53

Если нет, дайте нам знать, что вы получите.

Эта проблема может быть вызвана (, как я только что столкнулся ), с пустым resolv.conf, как это может быть в случае системы, использующей systemd-resolvedдля своего основного разрешения DNS через nsswitch.

Я предполагаю, что это случай, когда gpgне используется nsswitchи связанные с ним функции libc, а вместо этого по какой-то причине читается сам resolv.conf.

Симптомы:

• gpg: keyserver receive failed: Server indicated a failure

• /etc/resolv.confпусто, но разрешение имени хоста, например. getent hosts google.com, ping google.comи т.д. Обратите внимание, что dig, drill, nslookupвсе считывают resolv.confнапрямую, поэтому они могут не работать.

В

• /etc/nsswitch.confесть что-то вроде hosts: files mymachines myhostname resolve [!UNAVAIL=return] dns, где resolve— это модуль, предоставляемый systemd (подробности см. в man 8 libnss_resolve.so.2).

Разрешение:

Вы хотите создать символическую ссылку на автоматически сгенерированный файл resolv.confsystemd, отражающий текущие настройки преобразователя. Я предлагаю прочитать man 8 systemd-resolved, раздел "/ETC/RESOLV.CONF" для получения подробной информации о том, что именно это делает.

$ # you should check this has reasonable contents before using it
$ cat /run/systemd/resolve/stub-resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad

# rm /etc/resolv.conf
# ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

Эта ошибка появлялась при попытке получить доступ к ключу.

gpg: keyserver receive failed: No dirmngr

Уничтожение dirmngr и повторный запуск команды решили эту проблему для меня, как показано ниже:

gpgconf --kill dirmngr

Стоит попробовать, дайте мне знать, если получится.

Если вы проживаете в Беларуси , вам следует знать, что gpgпроблема может быть связана с новым глючным состоянием брандмауэра . Сегодня государственный брандмауэр в Беларуси может заблокировать hkpsс помощью DPIдля вас. На самом деле это ошибка :, вы можете сообщить о ней напрямую менеджерам брандмауэра , если считаете, что эта организация что-то изменит.

Если вы хотите вернутьhkps(и hkpи )обратно, вам необходимо следовать полному опыту работы с брандмауэром китайских пользователей :

1. удаленный openvpn сервер в обычной стране .
2. obfs4proxy сервер (пока не требуется ).
3. stunnel сервер.
4. внешний домен(azure)(пока не требуется ).
5. stunnel-клиент.
6. клиент obfs4proxy (пока не требуется ).
7. клиент openvpn.

См. также проблема gentoo .

Делюсь своими 2 днями устранения неполадок :Симптомы:

• gpg :ошибка получения сервера ключей :Сервер указал на сбой
• /etc/resolv.conf использует заглушку 127.0.0.53, но прекрасно разрешает имя хоста (, т.е. getent hosts google.com работают как положено)
• работает более 1 адаптера Ethernet

Устранение неполадок:

• открыть другой терминал и выполнитьjournalctl -u systemd-resolved -f
• в первом терминале сделатьsystemctl edit systemd-resolved

паста

 [Service]
 Environment=SYSTEMD_LOG_LEVEL=debug

перезагрузка

systemctl restart systemd-resolve<br/> sudo apt-key adv --keyserver
keyserver.ubuntu.com --recv-keys
F88F6D313016330404F710FC9A2FD067A2E3EF7B

Проверьте вспомогательный терминал, используемый им адаптер и неисправность. чтобы убедиться, что это причина, просто установите адаптер Ethernet и повторите запрос ключа, если он работает сейчас, вы можете понять, что у адаптера нет удовлетворительного сервера имен;

добавление 8.8.8.8 в конфигурацию сетевого плана 1-го адаптера решит проблему