Критическая ошибка NO_PUBKEY в Linux: диагностика причин, миграция с apt-key и современные методы восстановления GPG-ключей репозиториев

Знаете, что объединяет опытного системного администратора и новичка в Linux? Оба рано или поздно столкнутся с этим коварным сообщением: "GPG error: The following signatures were invalid: NO_PUBKEY". Но если новичок паникует, то администратор знает - перед ним не катастрофа, а всего лишь потерянное доверие системы к репозиторию.

Анатомия проблемы: почему система вдруг "забыла" репозиторий

Современные Linux-дистрибутивы работают по принципу "доверяй, но проверяй". Каждый пакет в репозитории подписывается криптографическим ключом разработчика. APT проверяет эти подписи перед установкой, защищая систему от подделок и вредоносного кода. Когда появляется NO_PUBKEY, это означает простую вещь: нужного ключа для проверки подписи в системе нет.

Причина устаревания apt-key заключается в том, что добавление ключа в связку ключей применяет ключ ко всем репозиториям. Представьте ситуацию: вы добавили ключ для небольшого стороннего репозитория, а через месяц его скомпрометировали. Злоумышленник может использовать этот ключ для подписи пакетов в любом репозитории, включая официальные.

Чаще всего проблема возникает в трех случаях. Первый - добавление новых репозиториев без импорта ключей. Второй - истечение срока действия ключей. Каждые 2-3 года команда Kali либо продлевает срок действия GPG-ключа, используемого для подписи APT-репозитория, либо заменяет его новым ключом. Третий случай - системные обновления, когда старые методы управления ключами перестают работать.

Реальная история: кризис ключей Kali Linux 2025

Весна 2025 года стала настоящим испытанием для пользователей Kali Linux. К началу мая 2025 года архив Kali подписывал пакеты новым ключом, и пользователи, следовавшие инструкциям, могли обновляться нормально. Но те, кто не обновил ключи вовремя, остались без возможности получать обновления.

Плохие новости для пользователей Kali Linux! В ближайшие дни apt update будет завершаться неудачей практически для всех: отсутствует ключ 827C8569F2518CC677FECA1AED65462EC8D5E4C5. Эта ситуация показала, насколько критично правильное управление ключами в современных дистрибутивах.

Решение оказалось относительно простым:

sudo wget https://archive.kali.org/archive-keyring.gpg -O /usr/share/keyrings/kali-archive-keyring.gpg

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

Почему apt-key стал историей

apt-key устарел и был удален в Debian 13 "Trixie". Долгие годы команда apt-key add решала проблему одной строкой, но содержала серьезную уязвимость. Ключ получал глобальное доверие для всех репозиториев системы.

После принятия решения об обновлении до 24.04.1 LTS эта проблема продолжает появляться. sudo apt-key add openvpn-repo-pkg-key.pub Предупреждение: apt-key устарел. Система выдает предупреждения, подталкивая администраторов к более безопасным методам.

Современный подход основан на принципе изолированного доверия. Каждый репозиторий получает собственный ключ через параметр signed-by в описании источника пакетов. Это радикально повышает безопасность, минимизируя риски компрометации.

Современная методология: пошаговое руководство

Когда в терминале появляется злополучное сообщение с идентификатором ключа, например 1234ABCD5678EFGH, начинается процесс восстановления доверия. Алгоритм действий зависит от источника ключа.

Метод первый: прямая загрузка с сервера

Когда разработчик предоставляет прямую HTTPS-ссылку на ключ, используем максимально безопасный способ:

sudo mkdir -p /usr/share/keyrings
curl -fsSL https://repo.example.com/key.asc | gpg --dearmor | sudo tee /usr/share/keyrings/example-keyring.gpg > /dev/null
sudo chmod 644 /usr/share/keyrings/example-keyring.gpg

Команда gpg --dearmor преобразует ASCII-формат ключа в бинарный, который понимает APT. Это критически важный шаг, поскольку большинство разработчиков публикуют ключи в текстовом формате.

Метод второй: получение с keyserver

Когда прямой ссылки нет, обращаемся к серверам ключей:

sudo gpg --no-default-keyring --keyring /usr/share/keyrings/example-keyring.gpg --keyserver keyserver.ubuntu.com --recv-keys 1234ABCD5678EFGH

Параметр --no-default-keyring предотвращает добавление ключа в личную связку пользователя. Если основной сервер недоступен, пробуйте альтернативные: hkp://keyserver.ubuntu.com:80 или keys.openpgp.org.

Настройка репозитория с изолированным доверием

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

echo "deb [signed-by=/usr/share/keyrings/example-keyring.gpg] https://repo.example.com/ubuntu $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/example.list
sudo apt update

Параметр signed-by - сердце новой системы безопасности. Он связывает репозиторий с конкретным ключом, предотвращая злоупотребления доверием.

Практические кейсы из реальной жизни

Docker: классический пример современного подхода

Официальный репозиторий Docker демонстрирует правильную реализацию новых стандартов:

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | gpg --dearmor | sudo tee /usr/share/keyrings/docker-archive-keyring.gpg > /dev/null

echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list

MongoDB: работа с архитектурно-специфичными ключами

Репозиторий MongoDB требует указания архитектуры и версии:

curl -fsSL https://pgp.mongodb.com/server-7.0.asc | gpg --dearmor | sudo tee /usr/share/keyrings/mongodb-server-7.0.gpg > /dev/null

echo "deb [arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-7.0.gpg] https://repo.mongodb.org/apt/ubuntu $(lsb_release -cs)/mongodb-org/7.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-7.0.list

Elasticsearch: обработка составных ключей

Некоторые проекты используют множественные ключи для разных компонентов:

wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | gpg --dearmor | sudo tee /usr/share/keyrings/elasticsearch-keyring.gpg > /dev/null

echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.x.list

Диагностика и устранение сложных случаев

Проблемы с сетевым доступом

Корпоративные сети часто блокируют стандартные порты keyserver. Решение - использование HTTP-портов:

sudo gpg --no-default-keyring --keyring /usr/share/keyrings/example.gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys KEYID

Если и это не работает, запросите у системного администратора доступ к keys.openpgp.org через HTTPS.

Истекшие и отозванные ключи

GPG-ключ используется для подписи репозитория для обеспечения подлинности, целостности и доверия при обновлении пакетов. Когда ключ истекает, система блокирует обновления. Проверить статус ключа можно командой:

gpg --no-default-keyring --keyring /usr/share/keyrings/example.gpg --list-keys --with-subkey-fingerprints

Конфликты прав доступа

Ключи должны быть читаемыми для всех пользователей:

sudo chown root:root /usr/share/keyrings/*.gpg
sudo chmod 644 /usr/share/keyrings/*.gpg

Проблемы с архитектурой

На системах ARM или других архитектурах добавляйте соответствующие параметры:

echo "deb [arch=arm64 signed-by=/usr/share/keyrings/example.gpg] https://repo.example.com/ubuntu $(lsb_release -cs) main"

Миграция со старых систем

Я часами искал решение, но все решения предлагают использовать apt-key. Однако это больше не работает, поскольку он устарел. Пользователи, обновляющие системы с Ubuntu 18.04 или более ранних версий, сталкиваются с множественными предупреждениями.

Инвентаризация существующих ключей

Первый шаг - определить, какие ключи установлены глобально:

sudo apt-key list

Экспорт ключей в новый формат

Для каждого ключа выполняем экспорт:

sudo apt-key export KEYID | gpg --dearmor | sudo tee /usr/share/keyrings/migrated-KEYID.gpg > /dev/null

Обновление sources.list файлов

Находим все упоминания репозиториев и добавляем параметр signed-by:

sudo find /etc/apt/sources.list.d/ -name "*.list" -exec grep -l "repo.example.com" {} \;

Очистка старых ключей

После успешной миграции удаляем устаревшие ключи:

sudo apt-key del KEYID

Автоматизация и скрипты для массового управления

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

#!/bin/bash
REPO_NAME="$1"
KEY_URL="$2"
REPO_URL="$3"
COMPONENTS="$4"

curl -fsSL "$KEY_URL" | gpg --dearmor | sudo tee "/usr/share/keyrings/$REPO_NAME-keyring.gpg" > /dev/null
echo "deb [signed-by=/usr/share/keyrings/$REPO_NAME-keyring.gpg] $REPO_URL $(lsb_release -cs) $COMPONENTS" | sudo tee "/etc/apt/sources.list.d/$REPO_NAME.list"
sudo apt update

Продвинутые техники и edge cases

Работа с зеркалами и CDN

Некоторые репозитории используют географически распределенные зеркала. Ключ должен работать для всех зеркал:

echo "deb [signed-by=/usr/share/keyrings/example.gpg] https://mirror1.example.com/ubuntu $(lsb_release -cs) main
deb [signed-by=/usr/share/keyrings/example.gpg] https://mirror2.example.com/ubuntu $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/example-mirrors.list

Обработка составных репозиториев

Крупные проекты часто используют несколько компонентов с разными ключами:

# Основной репозиторий
curl -fsSL https://example.com/main-key.asc | gpg --dearmor | sudo tee /usr/share/keyrings/example-main.gpg > /dev/null

# Экспериментальные пакеты
curl -fsSL https://example.com/experimental-key.asc | gpg --dearmor | sudo tee /usr/share/keyrings/example-experimental.gpg > /dev/null

Проверка целостности ключей

Всегда верифицируйте fingerprint ключей:

gpg --show-keys /usr/share/keyrings/example.gpg

Сравните отпечаток с официальным сайтом разработчика.

Мониторинг и профилактика

Создайте систему мониторинга статуса ключей:

#!/bin/bash
for keyring in /usr/share/keyrings/*.gpg; do
    echo "Checking $keyring:"
    gpg --no-default-keyring --keyring "$keyring" --list-keys --with-colons | awk -F: '/^pub/ {print "Key ID:", $5, "Expires:", $7}'
done

Настройте регулярную проверку истечения ключей в cron:

0 6 * * 1 /usr/local/bin/check-apt-keys.sh | mail -s "APT Keys Status" Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript.

Безопасность и лучшие практики

Никогда не добавляйте ключи из ненадежных источников. Всегда используйте HTTPS для загрузки ключей. Регулярно аудируйте установленные ключи и удаляйте неиспользуемые.

Новый ключ подписан несколькими разработчиками из команды Kali, и подписи доступны на сервере ключей Ubuntu OpenPGP. Это пример правильной практики - ключи должны иметь множественные подписи доверенных лиц.

Используйте принцип минимального доверия: каждый ключ должен работать только с предназначенным для него репозиторием. Регулярно обновляйте ключи согласно рекомендациям разработчиков.

Современная система управления GPG-ключами в Linux представляет собой значительный эволюционный скачок в области безопасности пакетного менеджера. Хотя новые методы требуют больше действий по сравнению с устаревшим apt-key, они обеспечивают надежную защиту от компрометации через сторонние репозитории. Инвестиции времени в освоение правильных процедур многократно окупаются повышенной безопасностью системы, спокойствием администратора и стабильной работой серверов в долгосрочной перспективе.