Как исправить 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
- Сделайте резервную копию
/etc/apt/sources.list.d/и/etc/apt/trusted.gpg. - Найдите URL репозитория в выводе
sudo apt update. - Скачайте официальный ключ в
/etc/apt/keyrings/repo.gpg. - Добавьте
signed-by=/etc/apt/keyrings/repo.gpgв.listилиSigned-By:в.sources. - Запустите
sudo apt update. - Убедитесь, что предупреждение исчезло.
- Только потом удаляйте старый ключ из
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-ключей. На сервере это особенно полезно: через год вы сами себе скажете спасибо, когда быстро поймёте, какой ключ за какой репозиторий отвечает.




А в сценариях, где на сервере уже накопилось несколько сторонних репозиториев, вы бы советовали хранить отдельный keyring на каждый источник или иногда допускаете один общий файл для похожих пакетов?
Я за отдельный keyring на каждый источник — так проще сопровождать, проще удалять старые репозитории и меньше шансов случайно сломать доверие к пакетам. Общий файл допустим только как временный костыль, но для нормальной эксплуатации лучше всё разнести по source-by-source схеме.
[…] Как исправить legacy trusted.gpg в APT и перейти на keyrings […]