GnuPG (Русский)

Состояние перевода:
На этой странице представлен перевод статьи
GnuPG
. Дата последней синхронизации: 9 октября 2023. Вы можете
помочь
синхронизировать перевод, если в английской версии произошли
изменения
.
Ссылки по теме
pacman/Подпись пакета
Data-at-rest encryption (Русский)
Список приложений/Безопасность#Шифрование, подписи и стеганография
В соответствии с официальной
веб-страницей
:
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
AUR
недоступен, 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
Смотрите также
Домашняя страница GNU Privacy Guard
Alan Eliasen's GPG Tutorial
RFC 4880
— "OpenPGP Message Format"
gpg.conf recommendations and best practices
Fedora:Creating GPG Keys
Debian:Subkeys
Protecting code integrity with PGP
A more comprehensive gpg Tutorial
/r/GPGpractice - сабреддит для тренировки использования GnuPG.