Многие базовые действия в дистрибутивах Linux не меняются множество лет и для многих стали уже привычкой. А привычки - вещь такая: привыкнуть легко, сложно переучиться. Поэтому изменения базовых вещей многими воспринимается в штыки и вызывает крайне негативные эмоции. Apt-key - утилита командной строки для управления ключами пакетного менеджера APT и когда ее объявили устаревшей, то многим это не понравилось. Однако на то были свои причины, а новая система управления ключами во многом даже проще и удобнее, нужно лишь разобраться и привыкнуть.
Онлайн-курс по устройству компьютерных сетей
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Коротко о том, что такое ключ репозитория и для чего он нужен. Любой репозиторий содержит пакеты, которые передаются по открытым каналам и перед тем, как устанавливать их в систему нам следует убедиться в их подлинности. Для этого все пакеты в репозитории подписаны закрытым ключом репозитория, а чтобы проверить их подлинность нам потребуется открытый ключ или просто ключ.
Для того, чтобы система могла использовать ключ его нужно установить в системное хранилище, которое располагается в /etc/apt/trusted.gpg, для чего использовалась команда:
apt-key add repo_signing.key
Однако если вы выполните команду в последних версиях Debian, Ubuntu и других основанных на них дистрибутивах, то получите предупреждение:
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
Ключ при этом добавится и, в принципе, вы можете продолжать пользоваться старым способом не обращая внимание на предупреждения.
Но разработчики не просто так объявили apt-key устаревшим, на это есть серьезные причины. Дело в том, что APT безоговорочно доверяет любому ключу в trusted.gpg для любого репозитория, что дает возможность загрузить из стороннего репозитория пакеты, подписанные ключом другого репозитория и заменить таким образом любой пакет в системе.
Чтобы устранить потенциальную брешь в безопасности была введена новая система, когда каждый репозиторий доверяет только собственному ключу, а сами ключи помещаются в специальное хранилище, к которому имеет доступ только суперпользователь. В настоящее время это директория /usr/share/keyrings, согласно документации там следует размещать ключи, дальнейшее управление которыми предполагается с помощью APT или DPKG. Для ключей управляемых локально предназначена директория /etc/apt/keyrings. В системах до Debian 12 и Ubuntu 22.04 ее следует создать самостоятельно с разрешением 755.
Ключ должен быть в двоичной форме (без ASCII-Armor) и иметь имя:
repo-archive-keyring.gpg
Где repo - короткая часть имени репозитория.
Допускается также иметь рядом текстовую версию ключа (с ASCII-Armor) с именем:
repo-archive-keyring.asc
Также в строке подключения репозитория можно явно указать связанный с ним ключ:
deb [signed-by=/usr/share/keyrings/repo-archive-keyring.gpg] ...
На практике очень часто требование снять ASCII-Armor не соблюдается и в /usr/share/keyrings кладется текстовая версия ключа. Однако в документации Debian крайне не советуется так делать.
Далее мы рассмотрим на практике приемы работы с ключами в современных операционных системах.
Определение типа ключа
Выше мы говорили, что ключ может быть двух типов: бинарный и текстовый, т.е. с ASCII-Armor или без. Пусть вас не смущает новый непонятный термин, ASCII-Armor - это привычный всем текстовый формат ключей в кодировке Base64.
Знакомо, не правда ли? Это и есть ключ с ASCII-Armor. Такие ключи наиболее распространены, так как текстовый формат более удобен при передаче в сетях связи. Убедиться, что перед вами ключ в ASCII формате можно просто прочитав файл, например, командой cat:
cat repo_signing.key
Или при помощи команды:
file repo_signing.key
В случае текстового формата вы увидите:
PGP public key block Public-Key (old)
Если это бинарный ключ:
OpenPGP Public Key Version 4
Почему мы уделяем этому столько внимания? Потому что если делать все по правилам, то ключи должны быть в бинарном формате, а для этого нужно понимать в каком виде мы получили исходный ключ. В большинстве случаев это будет текстовый ключ с ASCII-Armor.
Удаление старых ключей
Перед тем, как устанавливать ключ в новое хранилище нам нужно удалить его из старого хранилища /etc/apt/trusted.gpg. Для этого сначала получим список ключей командой:
apt-key list
В выводе будет полный список установленных в систему ключей.
Находим и копируем идентификатор нужного ключа, затем удаляем его командой:
apt-key del "KEY-ID"
Идентификатор можно взять как есть, с пробелами, только заключить его в двойные кавычки. Либо использовать два последних блока, так для указанного выше ключа можно ввести:
apt-key del D58C0CED
Кстати, именно эти две команды являются на сегодняшний день допустимыми для использования с apt-key.
Получение и установка текстовых ключей OpenPGP (c ASCII-Armor)
Адрес ключа репозитория обычно можно узнать в документации продукта, затем нам потребуется его скачать и установить в новое хранилище. Для скачивания можно использовать wget:
wget https://example.com/key/repo_signing.key
Или curl:
curl -O https://example.com/key/repo_signing.key
Затем его следует преобразовать в бинарный формат и поместить в хранилище, эту команду следует выполнять с правами суперпользователя:
gpg --dearmor < repo_signing.key > /usr/share/keyrings/repo-archive-keyring.gpg
Можно ли упростить этот процесс, можно, для этого используем конвейер:
wget -O- https://example.com/key/repo_signing.key | gpg --dearmor > /usr/share/keyrings/repo-archive-keyring.gpg
Или
curl https://example.com/key/repo_signing.key | gpg --dearmor > /usr/share/keyrings/repo-archive-keyring.gpg
Возможно, многие обратили внимание на чередование ключей в командах. Так wget по умолчанию скачивает файл, а curl выдает содержимое запроса в стандартный вывод. Поэтому чтобы сохранить файл с исходным именем мы использовали ключ -O для curl, и наоборот, чтобы получить содержимое файла в stdout мы запустили wget с ключом -O-, который предполагает вывод в файл, но если вместо файла указан дефис, то идет вывод в стандартный поток. Это небольшая мелочь, которую надо всегда помнить при работе с этими утилитами.
Обе команды должны быть запущены под root, если же вы предпочитаете sudo, то следует сделать так:
wget -O- https://example.com/key/repo_signing.key | gpg --dearmor | sudo tee /usr/share/keyrings/repo-archive-keyring.gpg >/dev/null
Или
curl https://example.com/key/repo_signing.key | gpg --dearmor | sudo tee /usr/share/keyrings/repo-archive-keyring.gpg >/dev/null
В чем разница? Основная часть работы выполняется с правами обычного пользователя, затем поток вывода передается утилите tee, которая записывает его в файл и выводит на экран, чтобы избежать последнего мы перенаправил ее вывод в /dev/null. При этом только tee запускается с правами суперпользователя.
Получение и установка бинарных ключей OpenPGP (без ASCII-Armor)
Мы бы хотели привести пример, но не можем припомнить чтобы в каком-то репозитории применялись бинарные ключи. Но случаи бывают разные. Для этого вам понадобятся права суперпользователя или sudo:
wget -O /usr/share/keyrings/repo-archive-keyring.gpg https://example.com/key/repo_signing.key
Или
curl -o /usr/share/keyrings/repo-archive-keyring.gpg https://example.com/key/repo_signing.key
Здесь все просто, мы сразу помещаем скачиваемый файл в хранилище под нужным именем.
Получение ключей OpenPGP с сервера ключей
Использование серверов ключей достаточно редкий сценарий, но он тоже иногда используется, и вы должны уметь это делать. Для того, чтобы получить ключ надо знать его ID, точнее два его последних блока:
gpg --keyserver keyserver.ubuntu.com --recv "KEY-ID"
Также вы можете использовать ID ключа целиком, если он содержит пробелы, то оберните его в двойные кавычки.
После выполнения данной операции в домашней директории пользователя будет создано локальное хранилище в скрытой директории .gnupg/trustdb.gpg.
Теперь нам нужно экспортировать оттуда ключ в хранилище, команда должна выполняться под тем же самым пользователем, который получил ключ в предыдущей команде, если это root:
gpg --export "KEY-ID" > /usr/share/keyrings/repo-archive-keyring.gpg
А если нужно получить текстовый ключ:
gpg --export --armor "KEY-ID" > /usr/share/keyrings/repo-archive-keyring.asc
Если ключ получал непривилегированный пользователь, то работаем через tee и sudo:
gpg --export "KEY-ID" | sudo tee /usr/share/keyrings/repo-archive-keyring.gpg >/dev/null
Можно ли сразу получить и экспортировать ключ? Можно. Если вы внимательно разобрали команды выше, то следующая не покажется вам китайским заклинанием:
gpg --no-default-keyring --keyring /usr/share/keyrings/repo-archive-keyring.gpg --keyserver keyserver.ubuntu.com --recv "KEY-ID"
Данную команду следует выполнять от имени суперпользователя, ключ --no-default-keyring предписывает не использовать локальное хранилище в домашней директории пользователя, оттуда не будет ничего считываться и не будет ничего записано.
Удаление ключей из хранилища
Для удаления ключа достаточно удалить соответствующий ему файл, для этого вам потребуются права root:
rm -f /usr/share/keyrings/repo-archive-keyring.gpg
Как видим, управлять ключами в современных системах несложно. Надеемся, что данная статья будет вам полезна и поможет быстрее перейти к использованию новых и безопасных инструментов.
Онлайн-курс по устройству компьютерных сетей
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Последние комментарии