Как исправить legacy trusted.gpg в APT и перейти на keyrings

После apt update на Debian или Ubuntu можно увидеть предупреждение:

Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg)

APT при этом обычно продолжает обновлять пакеты. Сервер не сломан, но предупреждение показывает старую схему доверия: ключ стороннего репозитория лежит в общем хранилище /etc/apt/trusted.gpg, а не в отдельном keyring-файле.

Современный вариант для APT — хранить ключи репозиториев отдельно, например в /etc/apt/keyrings/, и явно указывать их в источнике пакетов через signed-by. Тогда ключ Docker отвечает за Docker, ключ MongoDB — за MongoDB, а не все ключи лежат в одном общем котле.

Ниже — спокойный порядок миграции без резких движений: найти проблемный репозиторий, сделать резервную копию, перенести ключ в keyrings, прописать signed-by, проверить apt update и только после этого чистить старый trusted.gpg.

Почему появляется Key is stored in legacy trusted.gpg keyring

Старые инструкции часто добавляли ключи так:

curl -fsSL https://example.com/key.gpg | sudo apt-key add -

Или ключ вручную попадал в /etc/apt/trusted.gpg. Раньше это было привычно. Сейчас apt-key устарел, а APT подсказывает, что лучше перейти на keyrings.

Главная проблема не в предупреждении как таковом, а в слишком широкой области доверия. Если ключ лежит в общем trusted.gpg, сложнее понять, какой репозиторий он подтверждает. На сервере, где за годы добавляли Docker, NodeSource, MongoDB, InfluxData, PPA и ещё пару забытых источников, это превращается в кашу.

Новая схема понятнее:

• ключ хранится отдельным файлом, например /etc/apt/keyrings/docker.gpg;
• репозиторий содержит параметр signed-by=/etc/apt/keyrings/docker.gpg;
• APT использует этот ключ только для указанного источника пакетов.

Перед началом сделайте резервную копию APT-настроек

Не удаляйте ключи первым действием. Сначала сохраните текущие файлы:

sudo cp -a /etc/apt/sources.list /etc/apt/sources.list.backup.$(date +%F) 2>/dev/null || true
sudo cp -a /etc/apt/sources.list.d /etc/apt/sources.list.d.backup.$(date +%F)
sudo cp -a /etc/apt/trusted.gpg /etc/apt/trusted.gpg.backup.$(date +%F) 2>/dev/null || true

На боевом сервере лучше исправлять по одному репозиторию. Сначала Docker, затем проверка. Потом MongoDB, снова проверка. Так проще найти ошибку, если APT начнёт писать NO_PUBKEY или The following signatures couldn't be verified.

Шаг 1. Найдите репозиторий с legacy trusted.gpg

Запустите обновление:

sudo apt update

В выводе будет URL репозитория, например:

W: https://download.docker.com/linux/ubuntu/dists/jammy/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg)

Если предупреждений много, отфильтруйте только нужные строки:

sudo apt update 2>&1 | grep -i "legacy trusted.gpg\|trusted.gpg keyring"

Затем найдите файл, где подключён этот репозиторий:

grep -R "download.docker.com\|repo.mongodb.org\|repos.influxdata.com\|deb.nodesource.com" /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

Для общего просмотра сторонних репозиториев:

grep -R "^deb " /etc/apt/sources.list /etc/apt/sources.list.d/*.list 2>/dev/null

Если система использует deb822-формат .sources, проверьте и его:

grep -R "^URIs:\|^Signed-By:" /etc/apt/sources.list.d/*.sources 2>/dev/null

Шаг 2. Создайте каталог /etc/apt/keyrings

На актуальных Debian и Ubuntu удобно хранить сторонние ключи в /etc/apt/keyrings/:

sudo install -d -m 0755 /etc/apt/keyrings

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

sudo chmod a+r /etc/apt/keyrings/name.gpg

Вместо name.gpg будет имя конкретного репозитория: docker.gpg, nodesource.gpg, mongodb-server-7.0.gpg и так далее.

Шаг 3. Скачайте официальный ключ и пропишите signed-by

Лучший вариант — взять ключ заново из официальной инструкции репозитория. Не экспортировать всё подряд из trusted.gpg, а добавить только нужный ключ.

Общий шаблон:

curl -fsSL https://example.com/repo-key.asc | gpg --dearmor | sudo tee /etc/apt/keyrings/example.gpg >/dev/null
sudo chmod a+r /etc/apt/keyrings/example.gpg

Строка репозитория в .list должна выглядеть так:

deb [signed-by=/etc/apt/keyrings/example.gpg] https://example.com/repo stable main

Если используется .sources, то привязка задаётся отдельной строкой:

Types: deb
URIs: https://example.com/repo
Suites: stable
Components: main
Signed-By: /etc/apt/keyrings/example.gpg

Пример: Docker на Ubuntu

Для Docker ключ можно добавить так:

sudo install -d -m 0755 /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | gpg --dearmor | sudo tee /etc/apt/keyrings/docker.gpg >/dev/null
sudo chmod a+r /etc/apt/keyrings/docker.gpg

Пример строки репозитория:

deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu jammy stable

jammy замените на codename вашей Ubuntu. Проверить его можно так:

. /etc/os-release && echo "$VERSION_CODENAME"

Пример: MongoDB

У MongoDB версия ключа зависит от ветки. Для MongoDB 7.0 пример такой:

sudo install -d -m 0755 /etc/apt/keyrings
curl -fsSL https://pgp.mongodb.com/server-7.0.asc | gpg --dearmor | sudo tee /etc/apt/keyrings/mongodb-server-7.0.gpg >/dev/null
sudo chmod a+r /etc/apt/keyrings/mongodb-server-7.0.gpg

Строка репозитория:

deb [arch=amd64,arm64 signed-by=/etc/apt/keyrings/mongodb-server-7.0.gpg] https://repo.mongodb.org/apt/ubuntu jammy/mongodb-org/7.0 multiverse

Если у вас MongoDB 6.0 или 8.0, не меняйте только одну цифру наугад. Сверьте URL ключа и путь репозитория с официальной инструкцией под вашу версию системы.

Пример: InfluxData

Ключ InfluxData можно сохранить отдельным файлом:

sudo install -d -m 0755 /etc/apt/keyrings
curl -fsSL https://repos.influxdata.com/influxdata-archive_compat.key | gpg --dearmor | sudo tee /etc/apt/keyrings/influxdata.gpg >/dev/null
sudo chmod a+r /etc/apt/keyrings/influxdata.gpg

Пример для Debian Bookworm:

deb [signed-by=/etc/apt/keyrings/influxdata.gpg] https://repos.influxdata.com/debian bookworm stable

Для Ubuntu меняется путь и codename, но логика такая же: отдельный keyring и signed-by в источнике пакетов.

Пример: NodeSource

NodeSource часто встречается на серверах, где нужен свежий Node.js:

sudo install -d -m 0755 /etc/apt/keyrings
curl -fsSL https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key | gpg --dearmor | sudo tee /etc/apt/keyrings/nodesource.gpg >/dev/null
sudo chmod a+r /etc/apt/keyrings/nodesource.gpg

Пример репозитория для Node.js 20:

deb [signed-by=/etc/apt/keyrings/nodesource.gpg] https://deb.nodesource.com/node_20.x nodistro main

Если нужна другая ветка Node.js, меняется node_20.x.

Если ключ можно взять только из старого trusted.gpg

Иногда официальный URL ключа потерян, но репозиторий ещё нужен. Тогда можно перенести конкретный ключ из старого хранилища.

Посмотрите список ключей:

sudo apt-key list

Найдите нужный KEYID или fingerprint. После этого экспортируйте только этот ключ:

sudo apt-key export KEYID | gpg --dearmor | sudo tee /etc/apt/keyrings/repo-name.gpg >/dev/null
sudo chmod a+r /etc/apt/keyrings/repo-name.gpg

И пропишите его в репозитории:

deb [signed-by=/etc/apt/keyrings/repo-name.gpg] https://example.com/repo stable main

Это рабочий аварийный способ. Но если репозиторий живой и у него есть актуальная инструкция, лучше использовать свежий официальный ключ.

Почему не стоит просто переносить всё в trusted.gpg.d

Встречается быстрый рецепт: взять все ключи из /etc/apt/trusted.gpg и разложить их по /etc/apt/trusted.gpg.d/. Предупреждение часто исчезает, но проблема решается только внешне.

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

Шаг 4. Проверьте apt update

После правки одного репозитория выполните:

sudo apt update

Хороший результат:

• предупреждение про legacy trusted.gpg исчезло;
• нет ошибок NO_PUBKEY;
• нет ошибок EXPKEYSIG;
• нет сообщения The following signatures couldn't be verified.

Если появилась ошибка подписи, не удаляйте старый ключ. Сначала проверьте путь к keyring-файлу, права и правильность скачанного ключа.

Шаг 5. Удалите старый ключ после проверки

Когда новый signed-by работает, можно убрать старую запись:

sudo apt-key del KEYID

Перед удалением убедитесь, что этот ключ не использует другой репозиторий. На старых серверах такое бывает. Если сомневаетесь, оставьте удаление на отдельный этап. Главное предупреждение уже должно уйти после корректного signed-by.

Частые ошибки при переходе на APT keyrings

Осталась старая строка без signed-by

Проверьте дубли:

grep -R "example.com" /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

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

Ключ сохранён как текстовый .asc, а нужен .gpg

Приведите ключ к бинарному формату:

gpg --dearmor < repo-key.asc | sudo tee /etc/apt/keyrings/repo.gpg >/dev/null

APT не может прочитать keyring-файл

Проверьте права:

ls -l /etc/apt/keyrings/

И поправьте их:

sudo chmod a+r /etc/apt/keyrings/repo.gpg

В репозитории указан не тот codename

Проверьте codename системы:

. /etc/os-release && echo "$VERSION_CODENAME"

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

Быстрый чек-лист исправления legacy trusted.gpg

1. Сделайте резервную копию /etc/apt/sources.list.d/ и /etc/apt/trusted.gpg.
2. Найдите URL репозитория в выводе sudo apt update.
3. Скачайте официальный ключ в /etc/apt/keyrings/repo.gpg.
4. Добавьте signed-by=/etc/apt/keyrings/repo.gpg в .list или Signed-By: в .sources.
5. Запустите sudo apt update.
6. Убедитесь, что предупреждение исчезло.
7. Только потом удаляйте старый ключ из trusted.gpg.

FAQ

Можно ли оставить предупреждение и ничего не делать?

Технически можно, если обновления проходят без ошибок. Но на сервере лучше не копить такие хвосты. Через пару месяцев будет сложнее понять, какие ключи нужны, а какие давно забыты.

Нужно ли переносить ключи в /usr/share/keyrings или /etc/apt/keyrings?

Для локально добавленных сторонних репозиториев удобно использовать /etc/apt/keyrings. Каталог /usr/share/keyrings часто используют пакеты, которые сами устанавливают свои keyring-файлы.

Можно ли удалить apt-key?

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

Почему после переноса появился NO_PUBKEY?

Обычно APT не видит нужный ключ: неправильный путь в signed-by, файл не читается, ключ не dearmor-нут в .gpg или скачан не тот ключ.

Вывод

Предупреждение Key is stored in legacy trusted.gpg keyring не означает, что система сломалась. Оно означает, что APT нашёл старую схему доверия.

Лучше не просто «заткнуть» предупреждение переносом файлов в trusted.gpg.d, а привести репозитории к нормальному виду: отдельный keyring, signed-by, проверка, затем аккуратная чистка legacy-ключей. На сервере это особенно полезно: через год вы сами себе скажете спасибо, когда быстро поймёте, какой ключ за какой репозиторий отвечает.

Похожие материалы

• Ubuntu после окончания поддержки: old-releases и sources.list
• Как уменьшить размер логов journald в Linux без потери нужных данных
• Как создать символическую ссылку в Linux