Linux add gpg key

Записки IT специалиста

Аpt-key is deprecated или управление ключами в современных выпусках Debian и Ubuntu

Многие базовые действия в дистрибутивах Linux не меняются множество лет и для многих стали уже привычкой. А привычки — вещь такая: привыкнуть легко, сложно переучиться. Поэтому изменения базовых вещей многими воспринимается в штыки и вызывает крайне негативные эмоции. Apt-key — утилита командной строки для управления ключами пакетного менеджера APT и когда ее объявили устаревшей, то многим это не понравилось. Однако на то были свои причины, а новая система управления ключами во многом даже проще и удобнее, нужно лишь разобраться и привыкнуть.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Коротко о том, что такое ключ репозитория и для чего он нужен. Любой репозиторий содержит пакеты, которые передаются по открытым каналам и перед тем, как устанавливать их в систему нам следует убедиться в их подлинности. Для этого все пакеты в репозитории подписаны закрытым ключом репозитория, а чтобы проверить их подлинность нам потребуется открытый ключ или просто ключ.

Для того, чтобы система могла использовать ключ его нужно установить в системное хранилище, которое располагается в /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 — короткая часть имени репозитория.

Допускается также иметь рядом текстовую версию ключа (с ASCII-Armor) с именем:

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

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:

В случае текстового формата вы увидите:

PGP public key block Public-Key (old)

OpenPGP Public Key Version 4

Почему мы уделяем этому столько внимания? Потому что если делать все по правилам, то ключи должны быть в бинарном формате, а для этого нужно понимать в каком виде мы получили исходный ключ. В большинстве случаев это будет текстовый ключ с ASCII-Armor.

Удаление старых ключей

Перед тем, как устанавливать ключ в новое хранилище нам нужно удалить его из старого хранилища /etc/apt/trusted.gpg. Для этого сначала получим список ключей командой:

В выводе будет полный список установленных в систему ключей.

Находим и копируем идентификатор нужного ключа, затем удаляем его командой:

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

Кстати, именно эти две команды являются на сегодняшний день допустимыми для использования с apt-key.

Получение и установка текстовых ключей OpenPGP (c ASCII-Armor)

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

wget https://example.com/key/repo_signing.key

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

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник

How To Add An APT GPG Key

A common security measure implemented by APT repository maintainers is to sign the packages they distribute. This ensures that the packages you are installing are the authorized and unmodified packages issued by the package maintainers an no one else.

It can be a little confusing how to import the key into APT to install the new package in the first place. Here’s the easy way.

I just had to installed the excellent web log analyzer GoAccesss so I will use it as an example.

The first error was APT telling me that there was no GPG public key on my server for the GoAccess repository:

$ sudo apt update Get:5 http://deb.goaccess.io buster InRelease [2,336 B] Err:5 http://deb.goaccess.io buster InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 97BD1A0133449C3D Reading package lists. Done W: GPG error: http://deb.goaccess.io buster InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 97BD1A0133449C3D E: The repository 'http://deb.goaccess.io buster InRelease' is not signed. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. 

Your first step here is to find the public key for the repository. A search for “ public key” should get you the link you need. The GoAccess public key URL is https://deb.goaccess.io/gnugpg.key

Once you have the line use the following command to import the key:

Here with the GoAccess key URL:

wget -qO- https://deb.goaccess.io/gnugpg.key | sudo apt-key add - 

You can now apt update and apt install the new package.

Источник