Как исправить ошибку GPG: Не удалось проверить следующие подписи в Ubuntu

Начните с определения репозитория, вызвавшего предупреждение, затем исправьте ключ или конфигурацию этого репозитория. Не отключайте проверку подписи APT. Сообщение «Следующие подписи не удалось проверить» означает, что APT не может подтвердить, что метаданные репозитория были подписаны ключом, которому он доверяет. Пока подпись не будет проверена, APT может отказаться использовать этот источник. Добавление случайного ключа или установка источника в статус «доверенный» может скрыть предупреждение, но при этом лишит систему защиты, которую оно призвано обеспечивать.

Например, предположим, что sudo apt updateотчеты обновляются NO_PUBKEYдля репозитория поставщика браузера, а собственные строки архива Ubuntu обновляются успешно. Вероятным решением будет установить опубликованный в данный момент ключ подписи этого поставщика и привязать его к этому репозиторию. Переустановка хранилища ключей архива Ubuntu не решит проблему с ключом стороннего производителя. Приведенные ниже команды являются шаблонами: замените примеры сведений о репозитории значениями из официальных инструкций издателя программного обеспечения.

Перед сменой ключей внимательно прочтите текст ошибки.

Выполните команду обновления и запишите URL-адрес репозитория и код ошибки в тех же строках вывода:

sudo apt update

APT обычно идентифицирует источник по его URL-адресу и набору релизов, например noble, или jammy. Если настроено более одного источника, может отобразиться несколько ошибок. Перед внесением изменений сопоставьте каждое сообщение с соответствующим репозиторием. Эти распространенные сигнатуры указывают на разные причины:

Если в сообщении об ошибке указано время, сначала проверьте системное время.

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

timedatectl status

Убедитесь, что отображаемые дата и время точны и что синхронизация времени активна. Если часы показывают неверное время, исправьте службу времени хоста или включите настроенный метод синхронизации времени по сети, затем повторите попытку sudo apt update. Избегайте ручной установки приблизительной даты: часы должны показывать реальное время. Исправление времени не восстановит отсутствующий или просроченный ключ репозитория, поэтому, если сообщение об ошибке остается NO_PUBKEY, EXPKEYSIGпродолжите выполнение соответствующих шагов.

Исправьте отсутствующий или просроченный ключ стороннего репозитория.

В текущих рекомендациях Ubuntu предлагается хранить ключи сторонних разработчиков в отдельном связке ключей и ссылаться на этот ключ из соответствующего источника с помощью команды ` Signed-By.`. Это ограничивает круг ключей, которые могут аутентифицировать данный репозиторий. Ubuntu описывает этот подход в своем руководстве по сторонним репозиториям , а APT описывает Signed-Byпроверку областей действия в руководстве `sources.list` .

1. Найдите источник, вызвавший ошибку.

Просмотрите список записей репозитория и найдите хост, указанный в выводе APT:

grep -RniE '^[[:space:]]*(deb|URIs:)' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

В Ubuntu 24.04 и более поздних версиях обычно используются файлы deb822, заканчивающиеся на .sources; в более старых версиях обычно используются однострочные файлы, заканчивающиеся на .list. Документация по управлению пакетами Ubuntu описывает эти форматы исходного кода. Не редактируйте запись архива Ubuntu для восстановления репозитория стороннего поставщика.

2. Получите и проверьте текущий ключ издателя.

Откройте официальную страницу настройки репозитория издателя программного обеспечения и убедитесь, что там указаны URL-адрес репозитория, поддерживаемая версия Ubuntu, место загрузки ключа подписи и полный отпечаток ключа. Загружайте ключ только из источника, указанного издателем. Сравнивайте полный отпечаток, а не только короткий шестнадцатеричный идентификатор, показанный после NO_PUBKEY. В руководстве по безопасности APT подчеркивается необходимость получения ключей через доверенный канал; доверие к неправильному ключу подорвет проверку репозитория.

В следующем примере используется ключ в формате ASCII. Замените URL-адрес и имя файла из примера на официальные значения издателя:

curl -fsSLo /tmp/vendor-archive.asc https://packages.vendor.example/ubuntu/archive-key.asc
gpg --show-keys --with-fingerprint /tmp/vendor-archive.asc

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

sudo install -d -m 0755 /etc/apt/keyrings
gpg --dearmor --output /tmp/vendor-archive.gpg /tmp/vendor-archive.asc
sudo install -m 0644 /tmp/vendor-archive.gpg /etc/apt/keyrings/vendor-archive-keyring.gpg

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

3. Определите область действия ключа в исходном коде репозитория.

Для записи в одну строку .listиспользуется следующий шаблон:

deb [signed-by=/etc/apt/keyrings/vendor-archive-keyring.gpg] https://packages.vendor.example/ubuntu noble main

Для файла deb822 .sourcesсоответствующие поля выглядят следующим образом:

Types: deb
URIs: https://packages.vendor.example/ubuntu
Suites: noble
Components: main
Signed-By: /etc/apt/keyrings/vendor-archive-keyring.gpg

Это шаблоны, а не универсально допустимые записи в исходном коде. Сохраняйте URI, набор инструментов и компоненты из официальных инструкций по установке от поставщика; неправильное кодовое имя Ubuntu может привести к конфликтам пакетов, даже если ключ действителен. Убедитесь, что путь к связке ключей совпадает с установленным файлом. Связка ключей должна быть доступна для чтения непривилегированным _aptпользователем APT, поэтому в примере она устанавливается с правами доступа 0644. Удалите или исправьте дублирующиеся записи для одного и того же репозитория, чтобы старая запись без области видимости не продолжала вызывать предупреждение.

Команда APT apt-keyустарела для обычной настройки репозитория. Избегайте руководств, которые добавляют ключи сторонних разработчиков глобально apt-key advили помещают все ключи поставщиков в общий доверенный связку ключей. Signed-ByЗапись с ограниченной областью действия делает отношения доверия более понятными и уменьшает эффект доверия к одному ключу репозитория.

Если предупреждение относится к собственному архиву Ubuntu

Сначала убедитесь, что набор репозиториев соответствует установленной вами версии Ubuntu и что системное время установлено правильно. Ключи подписи архивов Ubuntu предоставляются пакетом ubuntu-keyring. Если установленный набор ключей поврежден или устарел, и APT по-прежнему может загружать и проверять пакеты из допустимого настроенного источника Ubuntu, переустановите его с помощью:

sudo apt install --reinstall ubuntu-keyring

Затем запустите sudo apt updateснова. Если единственной причиной сбоя является устаревший архив релиза или зеркало, предоставляющее несогласованные метаданные, переустановка связки ключей может не помочь. Перед изменением ключей проверьте поддержку релизов Ubuntu и конфигурацию репозитория. Не заменяйте ключ из архива Ubuntu ключом, загруженным с постороннего сайта, и не отключайте проверку для принудительного обновления.

Очищать кэшированные индексы следует только при несоответствии метаданных.

Если APT сообщает BADSIGо временных сбоях в сети или проблемах с зеркалом/прокси-сервером, локально кэшированные списки пакетов могут быть неполными или противоречивыми. После подтверждения легитимности настроенного источника очистите только кэшированные индексные файлы APT и загрузите их снова:

sudo rm -rf /var/lib/apt/lists/*
sudo apt update

Это удаляет загруженные индексы репозитория, а не установленные пакеты. APT перестроит индексы при следующем обновлении. Если BADSIGошибка возвращается немедленно, прекратите повторную очистку: проверьте, не перезаписывает ли сетевой прокси, кэширующий шлюз или зеркало несоответствующие метаданные, и проверьте статус репозитория у его издателя. Многократное удаление индексов не исправляет подпись, которую сам репозиторий публикует некорректно.

Подтвердите ремонт и оставьте защиту включенной.

Запустите программу sudo apt updateеще раз и убедитесь, что обработка затронутого репозитория завершается без предупреждений типа NO_PUBKEY, EXPKEYSIG, BADSIG, или проверки подписи. Затем проверьте пакет из этого источника с помощью команды apt-cache policy package-name, заменив имя на фактический пакет. Перед установкой или обновлением убедитесь, что его версия-кандидат получена из ожидаемого репозитория.

Не используйте trusted=yes, allow-insecure=yes, --allow-unauthenticated, или подобные опции в качестве постоянного решения. Проверка подписи APT подтверждает, что метаданные репозитория подписаны ключом, которому вы доверились; отключение этой проверки означает, что APT больше не сможет обеспечить проверку целостности. В руководстве по безопасности APT объясняется цепочка аутентификации архива и ее ограничения. Если издатель отозвал репозиторий, прекратил подписывать метаданные или не предоставляет проверяемый отпечаток ключа, удалите или отключите этот источник вместо того, чтобы обходить проверку.

Документация проверена 6 октября 2026 г. Форматы репозиториев Ubuntu и рекомендации по управлению ключами могут различаться в зависимости от версии; используйте документацию вашей установленной версии Ubuntu и текущие инструкции издателя репозитория.