GnuPG (Русский)

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

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

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

Установка

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

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

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

Настройка

Расположение каталогов

$GNUPGHOME используется GnuPG для определения каталога, в котором хранятся конфигурационные файлы. По умолчанию $GNUPGHOME не назначена и вместо этого используется $HOME; таким образом, вы найдете каталог ~/.gnupg сразу после установки.

Чтобы изменить стандартное расположение, выполните $ gpg --homedir путь/к/файлу или установите переменную окружения GNUPGHOME.

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

Tango-view-refresh-red.pngThis article or section is out of date.Tango-view-refresh-red.png

Reason: ~/.gnupg/dirmngr.conf больше не создаётся; возможно, потому что нет шаблонного файла в usr/share/doc/gnupg/ (Discuss in Talk:GnuPG (Русский))

Файлы конфигурации по умолчанию: ~/.gnupg/gpg.conf и ~/.gnupg/dirmngr.conf.

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

Добавляйте в эти файлы любые длинные опции, которые желаете. Не пишите две черты, просто имя опции и требуемые аргументы. Вы найдете шаблонные файлы (skeleton files) в /usr/share/gnupg. Эти файлы копируются в ~/.gnupg во время первого запуска gpg, если их там нет. Другие примеры можно найти в #Смотрите также.

В дополнение, 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 "дорого обходится", но почти ничего не даёт [1].
  • срок действия. Период в один год обычно достаточно хорош. В этом случае, даже если доступ к ключу будет потерян, он позволит другим узнать, что больше недействителен. Позже, при необходимости, срок действия может быть расширен без повторного выпуска нового ключа.
  • ваше имя и адрес электронной почты. Вы можете добавить несколько идентификаторов к одному и тому же ключу позже (например, если у вас есть несколько адресов электронной почты, которые вы хотите связать с этим ключом).
  • обязательный комментарий. Поскольку семантика поля комментария не определена, она имеет ограниченное значение для идентификации.
  • безопасная парольная фраза.
Примечание: Имя и адрес электронной почты, которые вы вводите здесь, будут видеть все, кто импортирует ваш ключ.
Совет: Более простая опция --gen-key использует параметры по умолчанию для шифра, размера и срока действия ключа и запрашивает только имя и адрес электронной почты.

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

  • Вывести список открытых ключей:
$ gpg --list-keys
  • Вывести список закрытых ключей:
$ gpg --list-secret-keys

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

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

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

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

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

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

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

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

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

$ gpg --import public.key

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

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

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

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

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

$ gpg --send-keys key-id
Важно: После отправки ключ будет невозможно удалить с сервера. Причина этого описана в MIT PGP Public Key Server FAQ.
Примечание: Связанный адрес электронной почты, будучи опубликованным публично, может стать целью спамеров, и в этом случае может потребоваться антиспам-фильтр.

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

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

$ gpg --search-keys user-id

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

$ gpg --recv-keys key-id
Важно:
  • Обязательно проверьте подлинность полученного открытого ключа, сравнив его отпечаток с тем, который владелец опубликовал в независимом источнике (например, связавшись с ним напрямую). Смотрите также статью на Википедии.
  • Для получения ключа рекомендуется использовать длинный ID ключа или полный отпечаток. С короткими ID могут случаться коллизии. Если несколько разных ключей имеют один и тот же короткий ID — будут импортированы все. Уже встречались поддельные ключи, у которых короткие ID совпадали с короткими ID ключей Линуса Торвальдса и Грега Кроа-Хартмана.
Совет: Добавление auto-key-retrieve в gpg.conf будет автоматически получать ключи с сервера ключей по мере необходимости, но это может рассматриваться как нарушение конфиденциальности; смотрите "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 931FF8E79F0876134EDDBDCCA87FF9DF48BF1C90
Совет:
  • Если при получении ключа появляется ошибка 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. Смотрите [2] для более подробной информации.
  • Можно подключиться к серверу ключей через прокси, указав переменную окружения http_proxy и прописав honor-http-proxy в dirmngr.conf. Также можно задать http-proxy хост[:порт] в файле настроек, чтобы переопределить параметры из переменной окружения. Перезапустите пользовательскую службу dirmngr.service для применения изменений.

Web Key Directory

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

# gpg --recipient [email protected] --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#Available methods, если вы хотите зашифровать каталоги или целую файловую систему.

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

Симметричное шифрование не требует генерации пары ключей и может использоваться для простого шифрования данных с помощью пароля. Просто используйте -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 privkey.asc user-id

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

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

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

$ gpg --import privkey.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, вам нужно будет отредактировать все файлы сокетов, чтобы использовать значения gpgconf --list-dirs. Имена сокетов используют хэш нестандартного домашнего каталога GnuPG [3], поэтому вы можете захардкодить его, не беспокоясь о том, что он изменится.

Настройка

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

~/.gnupg/gpg-agent.conf
default-cache-ttl 3600
Совет: Для кеширования вашего пароля на протяжении всей сессии, используйте команду:
$ /usr/lib/gnupg/gpg-preset-passphrase --preset XXXXXX

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

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

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

$ gpg-connect-agent reloadagent /bye

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

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

pinentry

gpg-agent использует pinentry для отображения диалога запроса пароля. Это настраивается в файле настроек gpg-agent.

По умолчанию используется диалог GTK. Однако, есть и другие варианты — смотрите подробнее в info pinentry. Чтобы установить другой диалог, установите опцию pinentry-program:

~/.gnupg/gpg-agent.conf
pinentry-program /usr/bin/pinentry-curses

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

Совет:
  • Чтобы использовать /usr/bin/pinentry-kwallet потребуется установить пакет kwalletcliAUR.
  • /usr/bin/pinentry-gtk-2 и /usr/bin/pinentry-gnome3 поддерживают DBus Secret Service API, который позволяет запоминать пароли через совместимый менеджер, такой как GNOME Keyring или KeePassXC.

После внесения изменений перезапустите gpg-agent.

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

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

Unattended passphrase

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

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

~/.gnupg/gpg-agent.conf
allow-loopback-pinentry

Перезапустите процесс gpg-agent чтобы изменения вступили в силу.

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

$ gpg --pinentry-mode loopback ...

либо добавьте ее же в файл настроек GnuPG:

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

Агент SSH

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

Установка SSH_AUTH_SOCK

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

SSH_AGENT_PID   DEFAULT=
SSH_AUTH_SOCK   DEFAULT="${XDG_RUNTIME_DIR}/gnupg/S.gpg-agent.ssh"
Примечание:
  • Если вы устанавливаете 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 [5].

Настройка 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 [6]:

~/.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", добавьте суффикс ! ([7]).

Если ваш ключ 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

Смарт-карты

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, такие как браузеры, может понадобиться перезапустить для применения этого изменения.

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

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

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

~/.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 <идентификатор> файл_пароля

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Доступно недостаточно случайных байтов

При генерации ключа gpg может отработать с такой ошибкой:

Not enough random bytes available. Please do some other work to give the OS a chance to collect more entropy!

Для проверки доступной энтропии, проверте параметры ядра:

cat /proc/sys/kernel/random/entropy_avail

Здоровая система Линукс с большим количеством доступной энтропии вернет значение близко к полным 4,096 бит энтропии. Если возвращенное значение менее 200, система имеет низкую энтропию.

Для решения этого, вам не стоит много раз создавать ключи, а лучше всего делайте то, что предлагает сообщение выше(например делайте активным диск, двигайте мышкой, редактируйте википедию - все это создает энтропию). Если это не помогает, проверьте какой сервис использует энтропию и рассмотрите временную его остановку. Если это не альтернатива, смотрите Random number generation#Alternatives.

su

При использовании pinentry, у вас должны быть корректные настройки прав доступа к устройству терминала (например /dev/tty1). Однако, с su (или sudo) права доступа остаются от прежнего пользователя системы. Из-за этого будут возникать проблемы с pinentry, даже при запуске от имени суперпользователя. Чтобы исправить эту проблему, назначьте нового владельца к устройству терминала до использования 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/. Одна из причин может быть в устаревшем файле опций. Подробности смотрите в отчете об ошибке.

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

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

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

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 при перезапуске).

Защита от отравленных 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)

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