Обновление apt завершается ошибкой NO_PUBKEY после добавления репозитория VPN

NO_PUBKEY и отсутствующий файл Release — это сбой доверия, а не сети. Решите, закрепить ли ключ поставщика через signed-by или удалить источник.

Источник apt вашего VPN-провайдера сломал менеджер пакетов, и исправление — это решение, а не команда. NO_PUBKEY, или жалоба на то, что в репозитории нет файла Release, означает, что apt отказался доверять этому источнику, поэтому каждая последующая операция с пакетами продолжает печатать одно и то же предупреждение. Сам туннель, вероятно, ни при чём. Ответьте на три вопроса о том, нужен ли вам ещё этот источник, и правильное исправление последует почти механически.

Сначала отнесите сбой к правильной категории

Сбой доверия называет файл источника и либо отсутствующий ключ, либо отсутствующий файл Release. Сбой передачи выглядит иначе: ошибки сертификата TLS, отказ в соединении, тайм-ауты или прокси, который отказывает в CONNECT. Это различие определяет, какую статью вы читаете, потому что VPN, перехватывающий TLS или блокирующий хост поставщика, даёт ошибки передачи, а не ошибки подписи.

Запустите sudo apt update отдельно и прочитайте конец, игнорируя закешированные строки выше. Важная строка называет /etc/apt/sources.list.d/ и говорит, какой файл открыть.

Если сбой появляется после поднятия туннеля, проверьте при опущенном туннеле и при DNS, разрешаемом системным резолвером. Источник, который работает без VPN, — это вопрос маршрутизации или перехвата, и никакое управление ключами это не исправит.

Три вопроса, которые выбирают путь

Вы всё ещё устанавливаете или обновляете пакеты из этого источника? Если клиент активно используется, почините доверие. Если вы установили клиент один раз и теперь импортируете обычный профиль в NetworkManager, источник — мёртвый груз, и удаление является честным исправлением.

Во-вторых, публикует ли поставщик ключ и отпечаток, которые можно проверить по независимому каналу? В-третьих, кто управляет ключами на этом хосте: дистрибутив или вы? Источник, подписанный ключом, который вы не можете проверить, — это право на обновления, которое не следует выдавать.

Ответ «нет» на первый вопрос завершает анализ. Ответ «да» на все три пункта ведёт к исправлению через signed-by, единственной схеме, которая одновременно работает и остаётся проверяемой. Смешивать оба пути, оставляя источник и проталкивая его силой, — единственный вариант, который стоит явно исключить.

Почему trusted=yes выглядит исправлением и им не является

Страница руководства по sources.list прямо об этом говорит. Установка параметра Trusted в yes велит apt принимать источник даже при неудачной аутентификации, что отключает apt-secure для этого репозитория. Страница оставляет это для локального контекста, если это вообще применяется.

Это не более узкая версия доверия поставщику. Это убирает вопрос о том, кто подписал индекс, поэтому любой, кто может отвечать за это имя хоста, может передать вашей машине пакеты, устанавливаемые с правами root.

Путь исправления: получите ключ, затем закрепите его

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

  1. Прочитайте неудачную строку, чтобы получить ID ключа и имя файла источника.
  2. Скачайте ключ поставщика в ASCII-броне и выполните gpg --dearmor в /etc/apt/keyrings/vendor-name.gpg.
  3. Добавьте [signed-by=/etc/apt/keyrings/vendor-name.gpg] к записи в файле .list этого поставщика.
  4. Выполните sudo apt update и убедитесь, что источник получает индекс, а не повторяет предупреждение о подписи.

Предпочитайте /usr/share/keyrings для ключей, которые приходят с пакетом, и /etc/apt/keyrings для ключей, которые вы кладёте вручную. Это разделение не косметическое: оно говорит следующему администратору, какие ключи переживут обновление пакета, а какие требуют человека.

Сверьте отпечаток с опубликованным значением поставщика, прежде чем доверять ему. ID ключа, вставленный из сообщения на форуме, — это путь, которым машина начинает доверять праву на обновления, которое никто не может назвать.

Путь удаления, и почему ошибка может вернуться

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

grep -r . /etc/apt/sources.list.d/
sudo rm /etc/apt/sources.list.d/vendor.list

apt читает из этого каталога только файлы .list и .sources, поэтому копия .save или .distUpgrade уже игнорируется; удаление всё равно не даст более позднему читателю случайно восстановить её. Удаление источника ничего не удаляет из системы, и apt может затем описать установленный пакет VPN как установленный локально или более недоступный, что является сообщением о состоянии пакета, а не возвратом ошибки доверия.

Повторяющийся случай — более старые инструкции, которые устанавливали ключи через apt-key в глобальное доверенное кольцо. Этот путь устарел, и обновление выпуска может оставить ключ отброшенным или просто неиспользуемым, и именно поэтому ошибка, молчавшая год, появляется на неделе вашего обновления. Проверьте /etc/apt/trusted.gpg.d/, затем перенесите решение о доверии в строку репозитория, где ему место. Если поставщик всё ещё печатает инструкции apt-key, всё равно используйте signed-by; это схема, которую документирует руководство, и та, что переживает обновление.

Похожие статьи