В этой статье разберёмся, почему привычный способ добавления репозиториев через apt-key в Ubuntu 24.04 больше не работает, как теперь правильно подключать сторонние источники пакетов с помощью GPG-ключей, и что делать, чтобы не словить неожиданные ошибки при апдейте или автоматизации серверов. Всё — на практике, с примерами, советами и лайфхаками для тех, кто хочет быстро и без лишней боли накатить нужные репы и не получить по шапке от системы безопасности.

Почему это важно и что изменилось?

Если ты когда-нибудь ставил на сервер MongoDB, Docker, Node.js или любой другой софт не из стандартных репозиториев, то наверняка сталкивался с apt-key. Раньше всё было просто: добавил ключ, прописал репозиторий — и поехали. Но времена меняются: начиная с Ubuntu 22.04, а теперь и в 24.04, apt-key официально признан устаревшим (deprecated). Его использование теперь не просто не рекомендуется — оно может привести к ошибкам, предупреждениям и даже отказу в установке пакетов.

Почему? Всё дело в безопасности. apt-key добавляет ключи в общий пул доверия, и если туда попадёт что-то лишнее — можно случайно довериться вредоносному репозиторию. Новая схема — хранить ключи отдельно для каждого источника, чтобы не было каши и рисков.

Как это работает: новая схема доверия GPG-ключей

• Раньше: apt-key add клал ключ в /etc/apt/trusted.gpg или /etc/apt/trusted.gpg.d/. Все репозитории доверяли всем ключам из этого списка.
• Теперь: Ключи хранятся в /usr/share/keyrings/, а каждый репозиторий явно указывает, каким ключом ему доверять через опцию signed-by в файле .list.

Это значит, что если ты добавляешь, например, репозиторий Docker, то его ключ будет лежать в /usr/share/keyrings/docker-archive-keyring.gpg, а файл /etc/apt/sources.list.d/docker.list будет выглядеть так:


deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu jammy stable


Теперь даже если кто-то подменит другой ключ — твой Docker останется под защитой.

Как быстро и просто всё настроить: пошаговая инструкция

Давай разберём на примере добавления репозитория Docker (аналогично для любого другого стороннего репозитория).

1. Скачиваем GPG-ключ и кладём его в /usr/share/keyrings/:
   
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

2. Добавляем репозиторий с указанием signed-by:
   
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 > /dev/null

3. Обновляем индексы пакетов:
   
sudo apt update

4. Устанавливаем нужный пакет:
   
sudo apt install docker-ce docker-ce-cli containerd.io


Всё! Никаких apt-key, никаких предупреждений, всё по феншую.

Примеры, схемы, практические советы

Давай сравним старый и новый подходы на примере MongoDB:

Старый способ (устарел)	Новый способ (рекомендуется)
wget -qO - https://www.mongodb.org/static/pgp/server-6.0.asc | sudo apt-key add - echo "deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu focal/mongodb-org/6.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-6.0.list sudo apt update	wget -qO - https://www.mongodb.org/static/pgp/server-6.0.asc | sudo gpg --dearmor -o /usr/share/keyrings/mongodb-server-6.0.gpg echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-6.0.gpg ] https://repo.mongodb.org/apt/ubuntu focal/mongodb-org/6.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-6.0.list sudo apt update
Минусы: – Предупреждения об устаревании – Все ключи в одном месте – Риск довериться лишнему источнику	Плюсы: – Безопасно – Нет предупреждений – Легко автоматизировать

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

• Положительный: Автоматизация установки Docker на 100+ серверов через Ansible. Используем gpg --dearmor и signed-by — ни одной ошибки, всё чисто, скрипты не ломаются после апдейта Ubuntu.
• Отрицательный: Старый bash-скрипт с apt-key add после обновления до 24.04 начинает сыпать ворнингами, а в будущем — просто откажет. Вручную приходится переписывать под новую схему.

Полный список команд для разных задач

• Скачать и сохранить GPG-ключ:
  
sudo curl -fsSL <URL_ключа> | sudo gpg --dearmor -o /usr/share/keyrings/<название>.gpg

• Добавить репозиторий с указанием ключа:
  
echo "deb [signed-by=/usr/share/keyrings/<название>.gpg] <URL_репозитория> <distro> <section>" | sudo tee /etc/apt/sources.list.d/<название>.list

• Обновить индексы пакетов:
  
sudo apt update

• Удалить устаревший ключ:
  
sudo apt-key list
sudo apt-key del <id_ключа>


Похожие решения, программы и утилиты

• Debian Wiki: UseThirdParty — официальная документация по добавлению сторонних репозиториев.
• apt-key(8) man page — подробности о депреке.
• Ubuntu Security FAQ — почему apt-key больше не катит.
• gpg — утилита для работы с ключами.

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

Метод	Безопасность	Совместимость	Автоматизация	Будущее
apt-key	Низкая	Устаревает	Проблемы	Deprecated
signed-by + keyrings	Высокая	Современно	Легко	Рекомендуется

Интересный факт: начиная с Ubuntu 24.04, apt-key даже не устанавливается по умолчанию! Если вдруг скрипт его вызывает — получите ошибку command not found.

Нестандартные способы использования

• Можно хранить ключи не только в /usr/share/keyrings/, но и в любом другом каталоге, если явно указать путь в signed-by. Это удобно для изолированных окружений или CI/CD.
• Для автоматизации в Ansible, SaltStack, Puppet теперь можно просто копировать нужный ключ и подставлять путь — никаких глобальных изменений в системе.
• Можно использовать несколько ключей для одного репозитория, если вдруг требуется поддержка нескольких подписей (редко, но бывает в enterprise-решениях).

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

• Больше не нужно париться с глобальными ключами — каждый проект может иметь свой keyring.
• Легко удалять/обновлять ключи без риска сломать другие репозитории.
• Возможность быстро деплоить новые репозитории через CI/CD, не боясь конфликтов.
• Можно хранить ключи в git-репозитории вместе с инфраструктурным кодом (например, в Ansible roles).

Выводы и рекомендации

Если ты хочешь, чтобы твои серверы на Ubuntu 24.04 (и новее) жили долго и счастливо, забудь про apt-key как про страшный сон. Используй новую схему с signed-by и отдельными GPG-ключами для каждого репозитория. Это не только безопаснее, но и проще для автоматизации, CI/CD и масштабирования инфраструктуры. Не ленись обновить свои старые скрипты и плейбуки — это инвестиция в стабильность и безопасность.

Если нужна быстрая и надёжная площадка для экспериментов — VPS или выделенный сервер — твой выбор. Всё остальное — дело техники и пары команд в терминале. Удачной настройки и пусть твои репозитории всегда будут под надёжной защитой!

---

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

Данная статья предназначена исключительно для ознакомительных и образовательных целей и не ущемляет права правообладателей. Если какой-либо материал, защищенный авторским правом, был использован без должного упоминания или с нарушением законов об авторском праве, это непреднамеренно, и мы исправим это незамедлительно после уведомления. Обратите внимание, что переиздание, распространение или воспроизведение части или всего содержимого в любой форме запрещено без письменного разрешения автора и владельца веб-сайта. Для получения разрешений или дополнительных запросов, пожалуйста, свяжитесь с нами.