GnuPG (Русский)

Состояние перевода: На этой странице представлен перевод статьи GnuPG. Дата последней синхронизации: 9 октября 2023. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

В соответствии с официальной веб-страницей:

GnuPG — полная и свободная реализация стандарта OpenPGP, определённого в RFC4880 (также известного как PGP). GnuPG позволяет вам шифровать и подписывать данные и сообщения. Он оснащён универсальной системой управления ключами, а также модулями доступа для всех типов открытых ключей. GnuPG, также известный как GPG, это инструмент командной строки с возможностью лёгкой интеграции с другими приложениями. Доступен богатый выбор пользовательских приложений и библиотек. GnuPG также поддерживает S/MIME и Secure Shell (ssh).

Установка

Установите пакет gnupg.

Примечание: Хотя текущая стабильная версия GnuPG — 2.4, пакет gnupg содержит версию 2.2. Если вам нужна версия 2.4, установите gnupg24^AUR^{[ссылка недействительна: package not found]}. Смотрите BBS#286519.

При этом будет установлен pinentry — набор простых диалоговых окон для ввода PIN-кода или парольной фразы, который использует GnuPG. Скрипт /usr/bin/pinentry определяет, какая конкретно реализация pinentry будет использоваться; смотрите раздел #pinentry.

Список программ, взаимодействующих с GnuPG, и графических фронтендов доступен в статье Список приложений/Безопасность#Шифрование, подписи и стеганография.

Настройка

Домашний каталог

Домашний каталог GnuPG — это место, где GnuPG хранит связки ключей, закрытые ключи и конфигурационные файлы. По умолчанию используется ~/.gnupg. Есть два способа задать свой путь:

с помощью переменной окружения $GNUPGHOME;
с помощью аргумента --homedir, например $ gpg --homedir путь/к/каталогу [1].

По умолчанию домашний каталог имеет права доступа 700, а содержащиеся в нём файлы — права доступа 600. Только владелец каталога имеет доступ к файлам. Это сделано в целях безопасности и не должно изменяться. Если каталог или какой-либо файл в нём не соблюдает эту меру безопасности, вы получите предупреждение о небезопасных правах доступа файлов и домашнего каталога.

Файлы конфигурации

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

gpg проверяет файлы gnupg_home/gpg.conf (пользовательский) и /etc/gnupg/gpg.conf (глобальный) [2]. Поскольку команда gpg является основной точкой входа в GnuPG, большинство настроек будет находиться здесь. Доступные опции описаны в GPG Options.
dirmngr проверяет файлы gnupg_home/dirmngr.conf и /etc/gnupg/dirmngr.conf. dirmngr — это внутренняя программа, которую gpg использует для доступа к серверам ключей PGP [3]. Доступные опции описаны в Dirmngr Options.

Эти два файла охватывают самые частые сценарии использования, но в GnuPG есть и другие вспомогательные программы со своими собственными опциями. Полный их перечень есть в GnuPG manual.

Создайте нужные файлы и задайте им права доступа 600, как обсуждалось в разделе #Домашний каталог.

Добавьте в эти файлы все необходимые длинные опции. Не пишите перед ними два дефиса, просто имя опции и требуемые аргументы. Например, чтобы GnuPG всегда использовал связку ключей по определённому пути, как если бы он был вызван с опцией gpg --no-default-keyring --keyring keyring-path ...:

gnupg_home/gpg.conf (или /etc/gnupg/gpg.conf)

no-default-keyring
keyring keyring-path

Другие примеры можно найти в разделе #Смотрите также.

В дополнение, pacman использует отдельный набор конфигурационных файлов для проверки подписи пакетов. Подробнее в статье pacman/Подпись пакета.

Стандартные настройки для новых пользователей

Если вы хотите задать какие-нибудь опции по умолчанию для новых пользователей, поместите соответствующие файлы в /etc/skel/.gnupg/. Когда новый пользователь будет добавлен в систему, файлы отсюда будут скопированы в его домашний каталог GnuPG. Также имеется простой скрипт addgnupghome, с помощью которого вы можете создать новые домашние каталоги GnuPG для существующих пользователей:

# addgnupghome user1 user2

Команда добавит /home/user1/.gnupg/ и /home/user2/.gnupg/ соответственно и скопирует туда файлы из каталога шаблонов (skeleton directory). Пользователи с существующими домашними каталогами GnuPG просто будут пропущены.

Использование

Примечание:

Всякий раз, когда команде требуется user-id, вы можете указать ваш key ID, отпечаток ключа (fingerprint), часть вашего имени, адреса электронной почты и т. д. GnuPG гибок в этом плане.
Когда требуется key-id, его можно найти добавлением опции --keyid-format=long к команде. Например, для просмотра закрытого мастер-ключа выполните gpg --list-secret-keys --keyid-format=long user-id, и key-id будет шестнадцатеричным значением, находящимся в строке sec.

Создание пары ключей

Создайте пару ключей, введя в терминал:

$ gpg --full-gen-key

Используйте опцию --expert, чтобы выбрать другие шифры, в частности эллиптическую криптографию (ECC).

Команда задаст несколько вопросов. Для общего использования большинству людей подойдут такие параметры:

RSA (только для подписи) и RSA (только для шифрования) ключ.
размер ключа по умолчанию (3072). Размер ключа 4096 «дорого обходится, но почти ничего не даёт» (смотрите why doesn’t GnuPG default to using RSA-4096).
срок действия. Период в один год обычно достаточно хорош. В этом случае, даже если доступ к ключу будет потерян, он позволит другим узнать, что больше недействителен. Позже, при необходимости, срок действия может быть расширен без повторного выпуска нового ключа.
ваше имя и адрес электронной почты. Вы можете добавить несколько идентификаторов к одному и тому же ключу позже (например, если у вас есть несколько адресов электронной почты, которые вы хотите связать с этим ключом).
пустой необязательный комментарий. Поскольку семантика поля комментария не определена, она имеет ограниченное значение для идентификации.
безопасная парольная фраза.

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

Совет: Более простая опция --gen-key использует параметры по умолчанию для шифра, размера и срока действия ключа и запрашивает только имя и адрес электронной почты.

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

Вывести список открытых ключей:

$ gpg --list-keys

Вывести список закрытых ключей:

$ gpg --list-secret-keys

Экспорт открытого ключа

Основное назначение GnuPG — обеспечение конфиденциальности обмена сообщениями с помощью криптографии с открытым ключом. С его помощью каждый пользователь распространяет открытый ключ своей связки ключей, который может быть использован другими пользователями для шифрования сообщений пользователю. Закрытый ключ всегда должен оставаться в тайне, иначе конфиденциальность будет нарушена. Подробнее о том, как это всё работает, можно почитать в статье на Википедии.

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

Чтобы сгенерировать ASCII-версию открытого ключа пользователя в файл public-key.asc (например, для отправки по электронной почте):

$ gpg --export --armor --output public-key.asc user-id

Ещё один вариант распространения открытого ключа — #Использование сервера ключей.

Совет:

Добавьте --no-emit-version, чтобы не выводить номер версии, или добавьте соответствующий параметр в ваш файл настроек.
Вы можете опустить user-id, чтобы экспортировать все открытые ключи в вашей связке ключей. Это полезно, если вы хотите поделиться несколькими идентификаторами одновременно или для импорта в другое приложение, например, Thunderbird.

Импорт открытого ключа

Чтобы зашифровать сообщения другим людям, а также проверить их подписи, вам нужен их открытый ключ. Чтобы импортировать открытый ключ из файла public-key.asc в свой список открытых ключей, выполните команду:

$ gpg --import public-key.asc

Другой вариант для поиска открытого ключа — #Использование сервера ключей.

Если вы хотите импортировать ключ для установки определённого пакета Arch Linux, смотрите pacman/Подпись пакета#Управление связкой ключей и makepkg (Русский)#Проверка цифровых подписей.

Использование сервера ключей

Отправка ключей

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

$ gpg --send-keys key-id

Важно: После отправки ключ будет невозможно удалить с сервера. Причина этого описана в MIT PGP Public Key Server FAQ.

Примечание: Связанный адрес электронной почты, будучи опубликованным публично, может стать целью спамеров, и в этом случае может потребоваться антиспам-фильтр.

Поиск и получение ключей

Чтобы посмотреть информацию о ключе на сервере ключей, не импортируя его, выполните:

$ gpg --search-keys user-id

Импортирование ключа с сервера ключей:

$ gpg --receive-keys key-id

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

$ gpg --refresh-keys

Важно:

Обязательно проверьте подлинность полученного открытого ключа, сравнив его отпечаток с тем, который владелец опубликовал в независимом источнике (например, связавшись с ним напрямую). Смотрите также статью на Википедии.
Для получения ключа рекомендуется использовать длинный ID ключа или полный отпечаток. С короткими ID могут случаться коллизии. Если несколько разных ключей имеют один и тот же короткий ID — будут импортированы все. Уже встречались поддельные ключи, у которых короткие ID совпадали с короткими ID ключей Линуса Торвальдса и Грега Кроа-Хартмана.

Совет: Добавление auto-key-retrieve в конфигурационный файл GnuPG включит автоматические получение ключей с сервера ключей по мере необходимости. Это не является компромиссом с точки зрения безопасности, но может рассматриваться как нарушение конфиденциальности; смотрите «web bug» в gpg(1).

Серверы ключей

Самые популярные серверы ключей:

Ubuntu Keyserver: федеративный, без проверки, ключи не могут быть удалены.
Mailvelope Keyserver: централизованный, проверка идентификаторов электронной почты, ключи могут быть удалены.
keys.openpgp.org: централизованный, проверка идентификаторов электронной почты, ключи могут быть удалены, нет подписей третьих лиц (т.е. нет поддержки Web of Trust).

Также можно посмотреть список серверов в Википедии.

Можно указать произвольный keyserver в настройках, например:

~/.gnupg/dirmngr.conf

keyserver hkp://keyserver.ubuntu.com

Временное использование другого сервера удобно, когда обычный сервер работает не так, как нужно. Например:

$ gpg --keyserver hkps://keys.openpgp.org/ --search-keys user-id

Совет:

Если при получении ключа появляется ошибка gpg: keyserver receive failed: General error и вы используете пул серверов hkps по умолчанию, убедитесь, что установлен сертификат проверки пула HKPS с помощью hkp-cacert /usr/share/gnupg/sks-keyservers.netCA.pem в вашем dirmngr.conf, и завершите старый процесс dirmngr.
Если при получении ключа появляется ошибка gpg: keyserver receive failed: Connection refused, попробуйте использовать другой DNS-сервер.
Можно подключиться к серверу ключей через Tor с помощью torsocks. Или можно использовать опцию --use-tor. Смотрите [4] для более подробной информации.
Можно подключиться к серверу ключей через прокси, указав переменную окружения http_proxy и прописав honor-http-proxy в dirmngr.conf. Также можно задать http-proxy хост[:порт] в файле настроек, чтобы переопределить параметры из переменной окружения. Перезапустите пользовательскую службу dirmngr.service для применения изменений.
Если при подключении к серверу ключей возникает ошибка gpg: keyserver receive failed: Server indicated a failure, возможно, необходимо настроить gpg на использование альтернативного порта. Например, чтобы использовать порт 80 для Ubuntu Keyserver, используйте keyserver hkp://keyserver.ubuntu.com:80.

Web Key Directory

Протокол Web Key Service (WKS) — это новый стандарт доставки ключей, в котором домен электронной почты предоставляет свой собственный сервер ключей, называемый Web Key Directory (WKD). При шифровании для адреса электронной почты (например, user@example.com) GnuPG (>=2.1.16) обратится к домену (example.com) через HTTPS для получения открытого ключа OpenPGP, если его ещё нет в локальном списке ключей. Опция auto-key-locate найдёт ключ по протоколу WKD, если в локальном списке ключей нет ключа для данного адреса электронной почты.

# gpg --recipient user@example.org --auto-key-locate --encrypt doc

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

Шифрование и дешифрование

Асимметричное

Перед шифрованием (опция -e/--encrypt) файла для указанного получателя (опция -r/--recipient) выполните #Импорт открытого ключа. Также выполните #Создание пары ключей, если её у вас ещё нет.

Шифрование файла с именем doc:

$ gpg --recipient user-id --encrypt doc

Чтобы расшифровать (опция -d/--decrypt) файл с именем doc.gpg, зашифрованный вашим открытым ключом:

$ gpg --output doc --decrypt doc.gpg

gpg спросит ваш пароль и затем расшифрует данные из файла doc.gpg в файл doc. Если опцию -o/--output не указывать, данные будут записаны в стандартный вывод (stdout).

Совет:

Опция --armor запишет вывод в ASCII-совместимом формате, пригодном для передачи в текстовых сообщениях.
Используйте -R user-id или --hidden-recipient user-id вместо -r, чтобы не помещать ID ключей получателей в зашифрованное сообщение. Это помогает скрыть получателей сообщения и является ограниченной контрмерой против анализа трафика.
Добавьте --no-emit-version, чтобы не выводить номер версии, или добавьте соответствующий параметр в ваш файл настроек.
Можно использовать GnuPG для шифрования конфиденциальных документов, используя свой собственный user-id в качестве получателя или используя флаг --default-recipient-self, однако вы можете делать это только с одним файлом за раз. Впрочем, можно собрать несколько файлов в один tar-архив и зашифровать уже его. Смотрите также Data-at-rest encryption (Русский)#Доступные методы, если вы хотите зашифровать каталоги или целую файловую систему.

Симметричное

Симметричное шифрование не требует генерации пары ключей и может использоваться для простого шифрования данных с помощью пароля. Просто используйте -c/--symmetric для выполнения симметричного шифрования:

$ gpg -c doc

Следующий пример:

Шифрует файл doc симметричным шифрованием с использованием пароля
Использует алгоритм шифрования AES-256 для шифрования данных
Использует алгоритм хэширования SHA-512 для генерации ключа шифрования из пароля
Выполняет 65536 итераций в процессе генерации ключа из пароля

$ gpg -c --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-count 65536 doc

Расшифровка симметрично зашифрованного doc.gpg с помощью пароля и вывод расшифрованного содержимого в тот же каталог, что и doc:

$ gpg --output doc --decrypt doc.gpg

Каталог

Можно зашифровать/расшифровать целый каталог с помощью gpgtar(1).

Шифрование:

$ gpgtar -c -o dir.gpg dir

Дешифрование:

$ gpgtar -d dir.gpg

Управление ключами

Резервное копирование закрытого ключа

Чтобы создать резервную копию вашего закрытого ключа, выполните:

$ gpg --export-secret-keys --armor --output private-key.asc user-id

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

Важно:

Пароль — обычно самое слабое звено в защите закрытого ключа. Поместите закрытый ключ в безопасное место на другой системе или на другом устройстве, например, в заблокированный контейнер или на зашифрованный диск. Это единственное средство защиты, которое поможет вам восстановить контроль над списком ваших ключей в случае, например, поломки диска, кражи или ещё чего-нибудь похуже.
Этот способ резервного копирования ключей имеет некоторые ограничения по безопасности. Более безопасный способ резервного копирования и импорта ключей с помощью gpg описан здесь.

Импорт закрытого ключа из резервной копии:

$ gpg --import private-key.asc

Совет: Paperkey позволяет экспортировать ключ в виде простого текста или машиночитаемого штрих-кода, которые можно отпечатать на бумаге.

Резервное копирование сертификата отзыва

Сертификаты отзыва автоматически генерируются для вновь создаваемых ключей. По умолчанию они находятся в ~/.gnupg/openpgp-revocs.d/. Имя файла сертификата — это отпечаток ключа, который он отзывает. Сертификаты отзыва также можно сгенерированы вручную с помощью следующей команды:

$ gpg --gen-revoke --armor --output revcert.asc user-id

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

Важно: Любой человек, имеющий доступ к сертификату отзыва, может публично отозвать ключ, и это действие нельзя отменить. Защищайте свой сертификат отзыва так же, как вы защищаете свой закрытый ключ.

Редактирование ключа

Команда gpg --edit-key user-id откроет меню, которое позволит вам выполнить большинство задач, связанных с управлением ключами.

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

> passwd      сменить фразу-пароль
> clean       сжать непригодные идентификаторы пользователей и удалить непригодные подписи из ключа
> revkey      отозвать ключ или выбранные подключи
> addkey      добавить подключ
> expire      сменить срок действия ключа или выбранных подключей
> adduid      добавить идентификатор пользователя
> addphoto    добавить фотоидентификатор

Совет: Если у вас есть несколько адресов электронной почты, вы можете добавить каждый из них в качестве идентификатора с помощью команды adduid. После этого можно установить нужный адрес в качестве основного (primary).

Экспорт подключей

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

Прежде всего, определите, какой подключ вы хотите экспортировать.

$ gpg --list-secret-keys --with-subkey-fingerprint

Укажите, что экспортировать нужно только конкретный подключ.

$ gpg -a --export-secret-subkeys [subkey id]! > /tmp/subkey.gpg

Важно: Если вы забудете добавить !, будут экспортированы все ваши подключи.

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

$ gpg --homedir /tmp/gpg --import /tmp/subkey.gpg
$ gpg --homedir /tmp/gpg --edit-key user-id
> passwd
> save
$ gpg --homedir /tmp/gpg -a --export-secret-subkeys [subkey id]! > /tmp/subkey.altpass.gpg

Примечание: Вы получите предупреждение о недоступности мастер-ключа и о том, что пароль не был изменён, но вы спокойно можете игнорировать это предупреждение, поскольку пароль для подключа был изменён.

Теперь вы уже можете использовать /tmp/subkey.altpass.gpg на других ваших устройствах.

Продление срока действия

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

Хорошей практикой является установка срока действия подключей, чтобы в случае потери доступа к ключу (например, если вы забудете пароль) он не мог использоваться другими пользователями неограниченное время. Когда срок действия ключа истекает, продлить дату истечения срока действия относительно просто:

$ gpg --edit-key user-id
> expire

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

Повторите это для всех остальных подключей, срок действия которых истекает:

> key 1
> expire

Наконец, сохраните изменения и выйдите из программы:

> save

Загрузите изменения на сервер ключей.

$ gpg --keyserver keyserver.ubuntu.com --send-keys key-id

Если вы используете этот ключ на нескольких компьютерах, можно экспортировать открытый ключ (с новыми подписанными датами истечения срока действия) и импортировать его на других компьютерах:

$ gpg --export --output pubkey.gpg user-id
$ gpg --import pubkey.gpg

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

Ротация подключей

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

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

Совет: Вам не обязательно создавать новый ключ только потому, что предыдущий просрочен. Вы всегда можете продлить срок ключа; смотрите раздел #Продление срока действия.

Создайте новый подключ (запустите дважды для создания отдельных ключей для подписывания и шифрования)

$ gpg --edit-key user-id
> addkey

При этом вам будет задано несколько вопросов (рекомендуемые настройки смотрите в разделе #Создание пары ключей).

Сохраните изменения

> save

Загрузите изменения на сервер ключей.

$ gpg --keyserver pgp.mit.edu --send-keys user-id

Также нужно сделать новую резервную копию; смотрите раздел #Резервное копирование закрытого ключа.

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

Отзыв ключа

Если ключ скомпрометирован, заменён, больше не используется или вы забыли пароль, необходимо отозвать ключ. Это делается путём слияния ключа с сертификатом отзыва ключа.

Если у вас больше нет доступа к вашей паре ключей, сначала выполните импорт собственного ключа (смотрите раздел #Импорт открытого ключа). Затем, чтобы отозвать ключ, импортируйте сертификат отзыва (нужно заранее создать его, как описано в разделе #Резервное копирование сертификата отзыва):

 $ gpg --import revcert.asc

Теперь нужно опубликовать информацию об отзыве ключа. Если вы ранее использовали публичный сервер PGP, отправьте на него отозванный ключ, как описано в разделе #Использование сервера ключей. В противном случае экспортируйте отозванный ключ в файл и распространите его среди ваших собеседников.

Подпись

Подписи позволяют проверить подлинность документов и ставят временные метки. Если документ будет изменён, проверка подписи будет неудачной. В отличие от шифрования, которое использует открытые ключи, подписи создаются с помощью закрытого ключа. Получатель подписанного документа затем проверяет подпись с помощью открытого ключа отправителя.

Создание подписи

Подпись файла

Для подписи файла используйте флаг -s/--sign:

$ gpg --output doc.sig --sign doc

Файл doc.sig будет содержать сжатое содержимое оригинального файла doc и подпись в бинарном формате. По умолчанию файл не будет зашифрован, но можно совместить подпись с шифрованием.

Подпись файла в текстовом формате

Для создания подписи в текстовом, а не в бинарном формате используйте флаг --clearsign:

$ gpg --output doc.sig --clearsign doc

Файл doc.sig будет содержать данные оригинального файла doc как есть и подпись в человекочитаемом формате.

Создание отделённой подписи

С помощью флага --detach-sig можно создать отдельный файл с подписью, который не будет содержать в себе данные оригинального файла:

$ gpg --output doc.sig --detach-sig doc

В файл doc.sig будет записана только подпись без содержимого файла doc. Этот метод часто используется при распространении программ, чтобы пользователи могли убедиться, что программа не была изменена третьей стороной.

Проверка подписи

Для проверки подписи используйте флаг --verify:

$ gpg --verify doc.sig

где doc.sig — это файл, содержащий подпись, которую вы хотите проверить.

Если это отделённая подпись, то для проверки должен присутствовать оригинальный файл. Например, для проверки iso-образа Arch Linux используйте:

$ gpg --verify archlinux-версия.iso.sig

где archlinux-версия.iso — проверяемый файл, который должен находиться в том же каталоге.

Также можно явно указать путь к проверяемому файлу:

$ gpg --verify archlinux-версия.iso.sig /путь/к/archlinux-версия.iso

Если файл был не только подписан, но ещё и зашифрован, просто расшифруйте файл, и его подпись будет автоматически проверена в процессе дешифрования.

gpg-agent

gpg-agent чаще всего используется как посредник для временного хранения пароля (пароль не будет запрашиваться каждый раз, когда нужен). Он полезен, если GnuPG используется внешней программой — например, почтовым клиентом. Пакет gnupg предоставляет пользовательские сокеты systemd, которые включены по умолчанию: gpg-agent.socket, gpg-agent-extra.socket, gpg-agent-browser.socket, gpg-agent-ssh.socket и dirmngr.socket.

Основной сокет gpg-agent.socket используется gpg для подключения к демону gpg-agent.
Предполагаемое использование gpg-agent-extra.socket на локальной системе — настройка переадресации Unix-сокета с удалённой системы. Это позволяет использовать gpg на удалённой системе без передачи на неё закрытых ключей. Смотрите gpg-agent(1) для более подробной информации.
gpg-agent-browser.socket позволяет веб-браузерам обращаться к демону gpg-agent.
gpg-agent-ssh.socket может использоваться SSH для кэширования ключей SSH, добавленных программой ssh-add. Настройка описана в разделе #Агент SSH.
dirmngr.socket запускает демон GnuPG, обрабатывающий соединения с серверами ключей.

Примечание: Если вы используете нестандартный #Домашний каталог GnuPG, вам нужно будет отредактировать параметр ListenStream (смотрите systemd.socket(5) § options) во всех socket-юнитах в соответствии со значениями из gpgconf --list-dirs. Имена сокетов используют хэш нестандартного домашнего каталога GnuPG [5], поэтому вы можете захардкодить его, не беспокоясь о том, что он изменится.

Настройка

gpg-agent можно настроить в файле ~/.gnupg/gpg-agent.conf. Все опции для настройки перечислены на странице gpg-agent(1). Например, так вы можете задать время жизни для ключей в кэше с момента последнего использования:

~/.gnupg/gpg-agent.conf

default-cache-ttl 3600

Совет: Для кеширования вашего пароля на протяжении всего сеанса используйте команду:

$ /usr/lib/gnupg/gpg-preset-passphrase --preset XXXXX

где XXXXX это keygrip. Вы можете получить это значение, запустив gpg --with-keygrip -K. Пароль будет храниться до перезапуска gpg-agent. Если установлено значение default-cache-ttl, оно более приоритетно.

Чтобы это работало, нужно разрешить такое кеширование путём запуска gpg-agent с опцией --allow-preset-passphrase или добавлением allow-preset-passphrase в файле ~/.gnupg/gpg-agent.conf.

Перезапуск агента

После обновления настроек перезапустите агент с помощью gpg-connect-agent:

$ gpg-connect-agent reloadagent /bye

Будет выведено сообщение OK.

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

pinentry

gpg-agent позволяет выбрать реализацию pinentry, которая используется в качестве интерфейса для ввода пароля, через опцию pinentry-program. Например:

~/.gnupg/gpg-agent.conf

pinentry-program /usr/bin/pinentry-curses

Посмотреть реализации pinentry, доступные в репозиториях, можно с помощью команды pacman -Ql pinentry | grep /usr/bin/. Может понадобиться установить опциональные зависимости для выбранной вами реализации.

Совет:

Чтобы использовать /usr/bin/pinentry-kwallet потребуется установить пакет kwalletcli^AUR.
Программы /usr/bin/pinentry-gnome3 (для GNOME) и /usr/bin/pinentry-gtk-2 (универсальная) [6] поддерживают DBus Secret Service API, который позволяет запоминать пароли в совместимом менеджере, таком как GNOME Keyring или KeePassXC.

Не забудьте выполнить #Перезапуск агента после внесения изменений.

Кэширование паролей

max-cache-ttl и default-cache-ttl определяют, сколько секунд gpg-agent должен кэшировать пароли. Чтобы вводить пароль всего один раз за сеанс, установите их на очень высокое значение, например:

gpg-agent.conf

max-cache-ttl 60480000
default-cache-ttl 60480000

Для кэширования паролей в режиме эмуляции SSH установите default-cache-ttl-ssh и max-cache-ttl-ssh, например:

gpg-agent.conf

default-cache-ttl-ssh 60480000
max-cache-ttl-ssh 60480000

Автоматический ввод пароля

Начиная с GnuPG 2.1.0, использование gpg-agent и pinentry стало обязательным; это нарушает обратную совместимость для парольных фраз, которые вводились через входной поток (STDIN) с помощью опции --passphrase-fd 0. Чтобы восстановить эту возможность, требуется выполнить несколько шагов.

Первым делом, отредактируйте настройки gpg-agent, разрешив режим петли (loopback) для pinentry:

~/.gnupg/gpg-agent.conf

allow-loopback-pinentry

Выполните #Перезапуск агента, чтобы изменения вступили в силу.

Теперь либо запускайте GnuPG с опцией --pinentry-mode loopback

$ gpg --pinentry-mode loopback ...

либо, если использовать опцию в командной строке невозможно, добавьте её в файл настроек GnuPG:

~/.gnupg/gpg.conf

pinentry-mode loopback

Примечание: Разработчики отмечают, что установка pinentry-mode loopback в файле настроек может нарушать другую функциональность GnuPG, и, если это возможно, лучше указывать опцию через командную строку. [7]

Агент SSH

gpg-agent имеет эмуляцию агента OpenSSH. Если вы уже используете пакет GnuPG, вы можете рассмотреть возможность использования его агента для кэширования ваших ключей SSH. Кроме того, некоторые пользователи могут предпочесть диалог ввода PIN-кода, который GnuPG agent предоставляет как часть управления парольной фразой.

Установка SSH_AUTH_SOCK

Чтобы связываться с gpg-agent и заменить стандартный ssh-agent, установите переменные окружения:

SSH_AGENT_PID=""
SSH_AUTH_SOCK="${XDG_RUNTIME_DIR}/gnupg/S.gpg-agent.ssh"

Примечание:

Если вы используете скрипт для установки переменных окружения, вы можете просто удалить переменную SSH_AGENT_PID вместо установки пустой строки: unset SSH_AGENT_PID.
Если вы устанавливаете SSH_AUTH_SOCK вручную, имейте в виду, что расположение сокета может отличаться, если вы используете нестандартный GNUPGHOME. Вы можете использовать приведённый ниже пример bash-скрипта или изменить SSH_AUTH_SOCK на значение gpgconf --list-dirs agent-ssh-socket.
Если установлен GNOME Keyring, необходимо деактивировать его ssh-компонент, иначе он перезапишет SSH_AUTH_SOCK.

Вариант с bash-скриптом, который поддерживает нестандартное расположение сокета:

~/.bashrc

unset SSH_AGENT_PID
if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then
  export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"
fi

Примечание: Тест, включающий переменную gnupg_SSH_AUTH_SOCK_by, предназначен для случая, когда агент запускается как gpg-agent --daemon /bin/sh, в этом случае оболочка наследует переменную SSH_AUTH_SOCK от родителя, gpg-agent [8].

Настройка pinentry для использования правильного TTY

Также укажите GPG_TTY и обновите TTY в случае, если пользователь перешёл в X-сессию, как указано в gpg-agent(1). Например:

~/.bashrc

export GPG_TTY=$(tty)
gpg-connect-agent updatestartuptty /bye >/dev/null

Если вы используете несколько терминалов одновременно и хотите, чтобы gpg-agent спрашивал пароль через pinentry-curses в том же терминале, в котором была запущена команда ssh, добавьте следующее в файл конфигурации SSH. Это заставит TTY обновляться каждый раз, когда выполняется команда ssh [9]:

~/.ssh/config

Match host * exec "gpg-connect-agent UPDATESTARTUPTTY /bye"

Для корректной работы должна быть указана переменная GPG_TTY.

Добавление ключей SSH

После запуска gpg-agent вы можете использовать ssh-add для одобрения ключей, выполнив действия, описанные в статье SSH keys#ssh-agent. Список одобренных ключей хранится в файле ~/.gnupg/sshcontrol.

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

Использование ключа PGP для аутентификации SSH

Можно использовать ключ PGP в качестве ключа SSH. Для этого требуется ключ с возможностью Authentication (смотрите раздел #Настройка возможностей). Это даёт некоторые преимущества:

Меньше работы по управлению ключами, поскольку вам больше не нужно будет поддерживать отдельный ключ SSH.
Возможность хранить ключ аутентификации на смарт-карте. GnuPG автоматически обнаружит ключ, когда карта будет доступна, и добавит его в агент (проверьте с помощью ssh-add -l или ssh-add -L). Комментарий к ключу должен быть примерно таким: openpgp:key-id или cardno:card-id.

Чтобы получить часть открытого ключа вашего ключа GPG/SSH, выполните gpg --export-ssh-key gpg-key. Если для ключа включена возможность аутентификации, но эта команда всё равно не работает с сообщением "Unusable public key", добавьте суффикс ! ([10]).

Если ваш ключ GPG не хранится на ключ-карте, вам нужно добавить ключ в $GNUPGHOME/sshcontrol, чтобы он был распознан как ключ SSH. Если ваш ключ находится на ключ-карте, его keygrip будет добавлен в sshcontrol неявно. Если нет, получите keygrip ключа таким образом:

$ gpg --list-keys --with-keygrip

sub   rsa4096 2018-07-25 [A]
      Keygrip = 1531C8084D16DC4C36911F1585AF0ACE7AAFD7E7

Затем отредактируйте sshcontrol следующим образом. Добавление keygrip — это однократное действие; вам не нужно будет редактировать файл снова, если вы не будете добавлять дополнительные ключи.

$GNUPGHOME/sshcontrol

1531C8084D16DC4C36911F1585AF0ACE7AAFD7E7

Доступ к gpg-agent и ssh-agent на удалённом устройстве

Как описано в GnuPG wiki, можно получить доступ к своему gpg-agent с удалённой машины, перенаправив на неё сокеты gpg с помощью SSH.

Сначала добавьте следующую строку в /etc/ssh/sshd_config на удалённой машине, чтобы включить автоматическое удаление старых сокетов при подключении. Без этого сокеты на удалённой машине придётся удалять вручную перед подключением с включенным перенаправлением, чтобы оно работало:

/etc/ssh/sshd_config

...
StreamLocalBindUnlink yes
...

Примечание: Перезагрузите службу sshd.service на удалённой машине для применения изменений.

На клиенте используйте директиву SSH RemoteForward для перенаправления трафика с удалённого порта на локальный. Как описано в ssh_config(5) § RemoteForward, параметрами этой директивы являются путь к слушающему сокету на удалённой стороне (той, на которую нужно пробросить агент), а затем путь к сокету назначения на локальном хосте (том, из которого пробрасывается агент). Конфигурация должна выглядеть примерно так:

~/.ssh/config

Host remote_name
    ...
    RemoteForward remote_agent_socket local_agent_extra_socket
    RemoteForward remote_agent_ssh_socket local_agent_ssh_socket

Первая строка настраивает переадресацию gpg-agent:

remote_agent_socket — вывод команды gpgconf --list-dir agent-socket на удалённом хосте.
local_agent_extra_socket — вывод команды gpgconf --list-dir agent-extra-socket на локальном хосте.

Вторая строка является необязательной. Она настраивает переадресацию ssh-agent:

local_agent_ssh_socket — вывод команды gpgconf --list-dir agent-ssh-socket на удалённом хосте.
remote_agent_ssh_socket — вывод команды gpgconf --list-dir agent-ssh-socket на локальном хосте.

Примечание: При переадресации ssh-agent на удалённом хосте должен быть установлен SSH_AUTH_SOCK в соответствии с выводом gpgconf --list-dirs agent-ssh-socket, как описано в разделе #Агент SSH).

Таким образом, с путями по умолчанию это будет выглядеть так:

    RemoteForward /run/user/1000/gnupg/S.gpg-agent /run/user/1000/gnupg/S.gpg-agent.extra
    RemoteForward /run/user/1000/gnupg/S.gpg-agent.ssh /run/user/1000/gnupg/S.gpg-agent.ssh

При такой конфигурации вызов ssh remote_name должен автоматически пробросить gpg-agent с вашего локального устройства на сервер, к которому вы подключаетесь, и позволить использовать там ваши gpg-ключи для расшифровки/подписи (и, если вы добавили вторую строку RemoteForward, то использовать ssh-agent тоже).

Смарт-карты

GnuPG использует scdaemon в качестве интерфейса к устройству для чтения смарт-карт. Для получения дополнительной информации обратитесь к man-странице scdaemon(1).

Настройка только для GnuPG

Примечание: Чтобы предоставить scdaemon прямой доступ к USB-считывателям смарт-карт, установите дополнительную зависимость libusb-compat.

Если вы не планируете использовать другие карты, кроме тех, что работают на основе GnuPG, необходимо проверить параметр reader-port в файле ~/.gnupg/scdaemon.conf. Значение '0' относится к первому доступному считывателю последовательного порта, а значение '32768' (по умолчанию) — к первому считывателю USB.

GnuPG вместе с pcscd (PCSC Lite)

pcscd(8) — это демон, который обрабатывает доступ к смарт-карте (SCard API). Если scdaemon не может подключиться к смарт-карте напрямую (например, используя встроенную поддержку CCID), он пытается найти смарт-карту с помощью драйвера PCSC Lite.

Для использования pscsd установите пакеты pcsclite и ccid. Затем запустите и/или включите службу pcscd.service. Вместо запуска демона напрямую можно запустить и/или включить pcscd.socket, тогда демон будет запускаться только по необходимости.

Всегда использовать pcscd

Если вы используете смарт-карту с драйвером opensc (например, ID-карты, распространённые в некоторых странах), необходимо уделить чуть большее время настройке GnuPG. Используя стандартную конфигурацию, при запросе gpg --card-status вы можете получать сообщения вроде этого:

gpg: selecting openpgp failed: ec=6.108

По умолчанию scdaemon пытается подключиться к устройству напрямую. Эта попытка провалится, если считыватель карт используется другим процессом. Например, если демон pcscd используется OpenSC. Чтобы справиться с этой ситуацией, необходимо использовать тот же самый драйвер, который использует opensc — тогда они смогут работать вместе. Чтобы заставить scdaemon использовать pcscd, необходимо удалить reader-port из файла ~/.gnupg/scdaemon.conf, указать путь к библиотеке libpcsclite.so и отключить ccid, чтобы удостовериться, что используется именно pcscd:

~/scdaemon.conf

pcsc-driver /usr/lib/libpcsclite.so
card-timeout 5
disable-ccid

Обратитесь к man-странице scdaemon(1), если вы не используете OpenSC.

Общий доступ с pcscd

GnuPG scdaemon — единственный популярный клиент pcscd, который использует флаг PCSC_SHARE_EXCLUSIVE при подключении к pcscd. Другие клиенты, такие как OpenSC PKCS#11, которые используются браузерами и программами, перечисленными в статье Electronic identification, используют PCSC_SHARE_SHARED, который даёт общий доступ к одной смарт-карте. pcscd не будет предоставлять эксклюзивный доступ к смарт-карте, пока подключены другие клиенты. Это означает, что для использования возможностей смарт-карты GnuPG вам придётся предварительно закрыть все открытые окна браузера или выполнить другие неудобные действия. Начиная с версии 2.2.28 LTS и 2.3.0, вы можете включить общий доступ, изменив файл scdaemon.conf и добавив pcsc-shared в конце.

Multi applet smart cards

При использовании YubiKey или других USB-ключей с несколькими апплетами с OpenSC PKCS#11 могут возникнуть проблемы, когда OpenSC переключает ваш Yubikey с апплета OpenPGP на апплет PIV, нарушая работу scdaemon.

Вы можете обойти эту проблему, заставив OpenSC также использовать апплет OpenPGP. Откройте файл /etc/opensc.conf, найдите Yubikey и измените строку driver = "PIV-II"; на driver = "openpgp";. Если такой записи нет, используйте pcsc_scan. Найдите Answer to Reset ATR: 12 34 56 78 90 AB CD .... Затем создайте новую запись.

/etc/opensc.conf

...
card_atr 12:23:34:45:67:89:ab:cd:... {
    name = "YubiKey Neo";
    driver = "openpgp"
}
...

После этого вы можете проверить с помощью pkcs11-tool -O --login, что апплет OpenPGP выбран по умолчанию. Другие клиенты PKCS#11, такие как браузеры, может понадобиться перезапустить для применения этого изменения.

Использование смарт-карты на удалённом клиенте через SSH

Если вы входите в машину по SSH и пытаетесь использовать подключенное устройство через pcscd, то можете обнаружить ошибки типа:

gpg: selecting card failed: No such device
gpg: OpenPGP card not available: No such device

Это связано с тем, что Polkit предоставляет доступ только локальным клиентам. Чтобы решить эту проблему, можно добавить правило, разрешающее доступ определённым пользователям во всех случаях. Приведённое ниже правило разрешает всем пользователям из группы wheel доступ к устройствам через pcscd:

/etc/polkit-1/rules.d/99-pcscd.rules

polkit.addRule(function(action, subject) {
    if (action.id == "org.debian.pcsc-lite.access_card" &&
        subject.isInGroup("wheel")) {
        return polkit.Result.YES;
    }
});
polkit.addRule(function(action, subject) {
    if (action.id == "org.debian.pcsc-lite.access_pcsc" &&
        subject.isInGroup("wheel")) {
        return polkit.Result.YES;
    }
});

После создания файла перезапустите службу polkit.service.

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

Другой алгоритм

Возможно, вы захотите использовать более сильные алгоритмы:

~/.gnupg/gpg.conf

...

personal-digest-preferences SHA512
cert-digest-algo SHA512
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
personal-cipher-preferences TWOFISH CAMELLIA256 AES 3DES

В последней версии GnuPG по умолчанию используются алгоритмы SHA256 и AES, которые достаточно безопасны для большинства пользователей. Однако если вы используете версию GnuPG старше 2.1 или если вы хотите получить ещё более высокий уровень безопасности, то вам стоит выполнить описанные выше действия.

Шифрование пароля

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

Первым делом создайте файл пароля, содержащий только ваш пароль и пустую строку. Обратите внимание: файл должен содержать одну пустую строку в конце, иначе gpg выведет сообщение об ошибке.

Теперь выполните:

$ gpg -e -a -r user-id файл_пароля

Опция -e обозначает режим шифрования, -a — для вывода в ASCII-совместимом формате, -r — идентификатор ключа.

После выполнения команды в текущем каталоге будет создан новый файл файл_пароля.asc.

Совет: pass автоматизирует этот процесс.

Изменение модели доверия

По умолчанию GnuPG использует модель доверия Web of Trust. Можно изменить эту модель на Trust on first use, добавив --trust-model=tofu при добавлении ключа или добавив эту опцию в файл настроек GnuPG. Более подробная информация содержится в этом письме GnuPG.

Скрытие всех идентификаторов получателей

По умолчанию в зашифрованном сообщении содержится идентификатор ключа получателя. Его можно удалить во время шифрования для получателя с помощью hidden-recipient user-id. Чтобы удалить его для всех получателей, добавьте throw-keyids в файл настроек. Это помогает скрыть получателей сообщения и является ограниченной контрмерой против анализа трафика (то есть, используя немного социальной инженерии, любой, кто способен расшифровать сообщение, может проверить, является ли один из других получателей тем, кого он подозревает). На стороне получателя это может замедлить процесс расшифровки, поскольку необходимо попробовать все доступные закрытые ключи (например, с помощью --try-secret-key user-id).

Использование caff на встречах для подписи ключей

Чтобы дать возможность пользователям проверить ключи в хранилищах ключей и в собственных списках (то есть убедиться, что владелец ключа на самом деле тот, за кого себя выдаёт), PGP/GnuPG использует так называемую «сеть доверия» (Web of Trust). Для поддержания и развития сети периодически организуются очные встречи, на которых люди, использующие систему PGP, обмениваются своими публичными ключами. Протокол Циммермана–Сассамана призван сделать этот процесс наиболее эффективным. Здесь вы можете найти инструкцию по проведению встреч.

Для упрощения процедуры подписи ключей и отправки этих подписей владельцам ключей вы можете воспользоваться утилитой caff. Установить её можно из AUR с пакетом caff-git^AUR.

Для отправки подписей владельцам вам нужен работающий агент MTA. Если у вас его ещё нет, установите msmtp.

Отображение длинных идентификаторов и отпечатков

Чтобы всегда показывать длинные идентификаторы ключей, добавьте keyid-format 0xlong в файл настроек. Чтобы всегда показывать полные отпечатки, добавьте with-fingerprint.

Настройка возможностей

Можно установить пользовательские возможности (capabilities) для ваших ключей. Доступны следующие возможности:

Сертификация (Certify, только для мастер-ключей) — позволяет ключу создавать подключи, обязательна для мастер-ключей.
Подпись (Sign) — позволяет ключу создавать криптографические подписи, которые другие могут проверить с помощью открытого ключа.
Шифрование (Encrypt) — позволяет любому человеку шифровать данные с помощью открытого ключа, расшифровать которые может только закрытый ключ.
Аутентификация (Authenticate) — позволяет использовать ключ для аутентификации в различных программах, не относящихся к GnuPG. Ключ можно использовать, например, в качестве ключа SSH.

Можно указать возможности мастер-ключа, выполнив команду:

$ gpg --full-generate-key --expert

И выбрав опцию, позволяющую задать собственные возможности.

Аналогично, чтобы задать возможности для подключей, добавьте флаг --expert в команду gpg --edit-key; смотрите раздел #Редактирование ключа.

Решение проблем

su

При использовании pinentry у вас должны быть корректные настройки прав доступа к устройству терминала (например /dev/tty1). Однако при использовании su (или sudo) права доступа остаются у изначального пользователя. Из-за этого будут возникать проблемы с pinentry, даже при запуске от имени суперпользователя. При попытке использовать ssh будет возникать ошибка sign_and_send_pubkey: signing failed: agent refused operation. Чтобы исправить эту проблему, назначьте нового владельца к устройству терминала до использования pinentry (например, перед запуском gpg-agent). При использовании gpg от имени суперпользователя просто измените владельца на root перед использованием gpg:

# chown root /dev/ttyN  # где N — текущий tty

Затем верните прежнего владельца после первого запуска gpg. Аналогично должно работать и для /dev/pts/.

Примечание: Владелец tty должен совпадать с пользователем, от имени которого запускается pinentry. Добавление пользователя в группу tty не поможет решить проблему.

Совет: Если вы запустите gpg через script, он будет использовать новый tty с правильным владельцем:

# script -q -c "gpg --gen-key" /dev/null

Agent выводит ошибку end of file

Если используется /usr/bin/pinentry-gnome3, для его правильной работы требуется запущенный DBus. Для получения дополнительной информации смотрите раздел Устранение часто встречающихся неполадок#Разрешения сессии.

Также можно использовать другую реализацию pinentry. Как это сделать, смотрите в разделе #pinentry.

Настройка прав доступа для KGpg

Некоторые пользователи сталкивались с проблемой, когда kgpg не может получить доступ к настройкам в ~/.gnupg/. Одна из причин может быть в устаревшем файле options. Подробности смотрите в отчёте об ошибке.

GNOME на Wayland переопределяет сокет агента SSH

В сеансах Wayland gnome-session устанавливает SSH_AUTH_SOCK на стандартный сокет gnome-keyring, $XDG_RUNTIME_DIR/keyring/ssh. Это переопределяет любое значение, установленное в другом месте.

Отключение такого поведения описано в статье GNOME/Keyring#Disabling.

mutt

Mutt может неправильно использовать gpg-agent, вам нужно установить переменную окружения GPG_AGENT_INFO (содержимое не имеет значения) при запуске mutt. Также убедитесь, что включено #Кэширование паролей.

Смотрите эту ветку форума.

"Потерявшиеся" ключи после обновления до GnuPG 2.1

Если команда gpg --list-keys перестала отображать какие-то ключи, а приложения ругаются на отсутствующие/повреждённые ключи, вероятно, какие-то ключи не были сконвертированы в новый формат.

Прочтите исправление ошибки Invalid packet. Здесь говорится, что существует баг с ключами в старых файлах pubring.gpg и secring.gpg, которые были заменены файлом pubring.kbx и подкаталогом private-keys-v1.d/. Потерянные ключи можно восстановить следующими командами:

$ cd
$ cp -r .gnupg gnupgOLD
$ gpg --export-ownertrust > otrust.txt
$ gpg --import .gnupg/pubring.gpg
$ gpg --import-ownertrust otrust.txt
$ gpg --list-keys

gpg зависает на всех серверах ключей (при попытке получения ключей)

Если gpg зависает на определённом сервере ключей, когда пытается получить ключи, вам придётся убить dirmngr для того, чтобы получить доступ к другим действительно рабочим серверам, в противном случае gpg останется зависшим для всех них.

Смарт-карта не обнаружена

Возможно, пользователь, из-под которого вы работаете, не имеет права доступа к смарт-карте, вследствие чего и возникает card error, даже если карта корректно настроена и установлена.

Одно из возможных решений — добавить новую группу scard с включением в неё пользователей, которым нужен доступ к смарт-карте.

Дальше используйте подобное правило udev:

/etc/udev/rules.d/71-gnupg-ccid.rules

ACTION=="add", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="1050", ENV{ID_MODEL_ID}=="0116|0111", MODE="660", GROUP="scard"

Только нужно адаптировать VENDOR и MODEL в соответствии с выводом lsusb. Выше приведён пример для YubikeyNEO.

server 'gpg-agent' is older than us (x < y)

Это предупреждение появляется, если gnupg был обновлён, а старый gpg-agent всё ещё запущен. Перезапустите пользовательский gpg-agent.socket (т.е. используйте флаг --user при перезапуске).

IPC connect call failed

Убедитесь, что gpg-agent и dirmngr не запущены, с помощью команды killall gpg-agent dirmngr, и проверьте права доступа к каталогу $GNUPGHOME/crls.d/, которые должны быть 700.

По умолчанию пакет gnupg использует для сокетов каталог /run/user/$UID/gnupg/. В документации GnuPG указано, что это предпочтительный каталог (не все файловые системы поддерживают сокеты). Убедитесь, что в конфигурации agent-socket указан путь к поддерживающей сокеты файловой системе. Настройки пути для agent-socket можно узнать, выполнив команду gpgconf --list-dirs agent-socket.

Проверьте, что gpg-agent успешно запускается, с помощью команды gpg-agent --daemon.

Защита от отравленных PGP-сертификатов

В июне 2019 года неизвестный злоумышленник заспамил PGP-сертификаты некоторых высокопоставленных участников сообщества десятками тысяч (или сотнями тысяч) подписей (CVE-2019-13050) и загрузил эти подписи на серверы ключей SKS. Существование этих отравленных сертификатов в списке ключей приводит к зависанию gpg со следующим сообщением:

gpg: removing stale lockfile (created by 7055)

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

Invalid IPC response и Inappropriate ioctl for device

По умолчанию программой pinentry является /usr/bin/pinentry-gtk-2. Если gtk2 недоступен, pinentry пытается использовать /usr/bin/pinentry-curses, что приводит к сбою подписания:

gpg: signing failed: Inappropriate ioctl for device
gpg: [stdin]: clear-sign failed: Inappropriate ioctl for device

Установите переменную окружения GPG_TTY для программ /usr/bin/pinentry-tty и /usr/bin/pinentry-curses.

$ export GPG_TTY=$(tty)

Keyblock resource не существует

Если при попытке импортировать ключи вы получаете ошибку:

gpg: keyblock resource 'gnupg_home/pubring.kbx': No such file or directory

это потому что GnuPG не создаст свой домашний каталог, если его ещё нет. Просто создайте его вручную:

$ mkdir -m 700 gnupg_home

Смотрите также