SSH через GPG: использовать GPG-ключ для SSH

Фотография офисного пространства с людьми, работающими за компьютерами.

Зачем использовать GPG-ключи для входа по SSH

GPG-ключи удобны тем, что их легко переносить между хостами и платформами. Практически в каждой ОС есть инструменты для работы с GPG: графические (например, Kleopatra на Windows/Linux) и консольные (gpg на Linux и macOS). Одна строка определения: GPG — это система публичного шифрования и подписи, совместимая с OpenPGP.

Скриншот GNU Kleopatra с отображением GPG-ключа.

Плюсы метода:

Унификация: один ключ — несколько задач (SSH, подпись писем, шифрование файлов).
Мобильность: GPG-агент предоставляет стандартный SSH-сокет, который можно подключить локально.
Минимальное изменение инфраструктуры: GPG умеет экспортировать «SSH-совместимый» публичный ключ, который сервер принимает как обычный ключ SSH.

Терминал с GPG-ключом и несколькими субключами.

Важно: этот подход не заменяет лучшие практики управления доступом. Он упрощает ротацию и уменьшает число приватных ключей, но не отменяет необходимости ограничивать доступ и применять SSO/2FA там, где это нужно.

Подготовка GPG-ключа для использования с SSH

Цель — создать отдельный под ключ (subkey) с возможностью аутентификации (auth). Так вы сможете делиться SSH-доступом, не подвергая риску ваш основной ключ подписи/шифрования.

Выведите редактор ключа для вашего основного ключа:

gpg --expert --edit-key YOUR-KEY@EMAIL.ADDRESS

Примечание: email можно найти с помощью gpg --list-keys.

В промпте gpg введите addkey, затем выберите опцию для RSA (обычно это пункт 8 в экспертном режиме), нажмите Enter.
На приглашении возможностей укажите A (auth) — под ключ будет использоваться только для аутентификации SSH.
Укажите размер ключа 4096 и подтвердите.
Установите срок действия подписи, например 1y для годовой валидности. Это хорошая практика: короткий срок уменьшает риск длительного использования скомпрометированного ключа.
Подтвердите создание под ключа (y), затем выйдите командой quit.

Проверьте результат:

gpg --list-keys YOUR-KEY@EMAIL.ADDRESS

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

Терминал, показывающий установку capability

Терминал с указанием keysize и срока действия субключа.

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

Включение поддержки SSH в gpg-agent

Теперь нужно настроить агент GPG так, чтобы он предоставлял SSH-сокет и мог работать как посредник для SSH-аутентификации.

Добавьте опцию enable-ssh-support в конфигурацию gpg-agent текущего пользователя:

echo "enable-ssh-support" >> ~/.gnupg/gpg-agent.conf

Откройте ваш профиль оболочки (в примере — .bashrc) и экспортируйте переменную окружения для SSH_AUTH_SOCK, а также запустите агент:

nano ~/.bashrc

В конец файла добавьте:

export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)
gpgconf --launch gpg-agent

Сохраните и примените изменения для текущей сессии:

source ~/.bashrc

Выведите keygrip для ваших ключей — это уникальный идентификатор, который gpg использует для управления ключами:

gpg --list-keys --with-keygrip

Терминал с выделенным keygrip субключа GPG.

Скопируйте keygrip соответствующего субключа и создайте файл sshcontrol в каталоге .gnupg, поместив туда один keygrip на строку:

nano ~/.gnupg/sshcontrol

Вставьте keygrip и сохраните файл.

Терминал, показывающий keygrip субключа в файле sshcontrol.

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

ssh-add -L

Если команда вернёт список публичных ключей — агент успешно работает.

Экспорт и проверка SSH-ключа из GPG

Чтобы удалить барьер для входа на серверы, экспортируйте SSH-совместимый публичный ключ из GPG и поместите его в файл authorized_keys на сервере.

Сгенерируйте SSH-публичный ключ для экспорта:

gpg --ssh-export-key YOUR-KEY@EMAIL.ADDRESS > ~/authorized_keys

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

chmod 600 ~/authorized_keys

Передайте файл на сервер (замените YOUR-REMOTE.SERVER.DOMAIN на адрес):

scp ~/authorized_keys YOUR-REMOTE.SERVER.DOMAIN:~/.ssh/authorized_keys

Перезайдите на сервер и перезапустите SSH-демон (если требуется):

sudo systemctl restart ssh.service

Выйдите из сессии (Ctrl+D) и попробуйте подключиться снова. Должен появиться запрос пароля от вашего основного GPG-ключа (или от PIN, если вы используете смарт-карту).

Скриншот запроса пароля Gnome GPG при попытке SSH-входа.

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

Когда этот подход может не подойти

Устройства без установленного gpg-agent. В этом случае нужно установить и настроить GnuPG.
Среда с жесткой политикой безопасности, требующей отдельного аппаратного токена для SSH, где соединение через gpg-agent не разрешено.
Если у вас централизованная система управления ключами (например, корпоративная HSM или PAM-плагин), лучше подчиниться корпоративной политике.

Альтернативные подходы

Использовать обычные SSH-ключи (ed25519/ecdsa) и менеджеры ключей (ssh-agent). Простая и широко поддерживаемая схема.
Аппаратные токены (YubiKey, Nitrokey) для хранения SSH-ключа отдельно от ОС.
SSO/OTP/2FA через провайдеров (Okta, GitHub, Auth0) для дополнительного уровня контроля доступа.

Ментальные модели и правила принятия решений

Если вы управляете множеством сервисов и хотите сократить количество приватных ключей — GPG подойдёт.
Если вам важна максимальная совместимость и простота — используйте стандартные SSH-ключи ed25519.
Для корпоративных серверов следуйте политике безопасности и согласуйте хранение ключей с отделом ИБ.

Руководство для ролей (короткий чеклист)

Администратор:

Создать под ключ с capability A.
Настроить gpg-agent и sshcontrol.
Объяснить пользователям процедуру ротации ключей.

Разработчик:

Импортировать ваш публичный ключ в ~/.ssh/authorized_keys на тестовых серверах.
Проверить ssh-add -L и выполнить пробный вход.

Оперативный персонал (on-call):

Иметь запасной канал доступа (консоль сервера или KVM).
Знать процедуру отката (удаление записи authorized_keys).

Безопасность и повышение стойкости

Используйте длинные ключи (4096 бит для RSA) или предпочитайте ed25519 для обычных SSH-ключей.
Ограничьте срок действия подписи(subkey) и планируйте регулярную ротацию.
Храните основной ключ в защищённом месте и используйте PIN/пароль.
Запрещайте доступ к gpg-agent внешним пользователям и следите за правами файлов в ~/.gnupg.

Частые проблемы и их решение

ssh-add -L ничего не показывает: проверьте, что gpg-agent запущен и SSH_AUTH_SOCK указывает на gpg-конфигурацию.
Сервер отказывает в доступе: проверьте, что публичный ключ корректно записан в ~/.ssh/authorized_keys и права файла установлены 600.
Нужен пароль GPG при каждом подключении: рассмотрите использование gpg-agent с кешированием PIN или аппаратным токеном.

Краткая методология внедрения (шаги для проекта)

Оцените инфраструктуру и определите список серверов.
Создайте субключи с capability auth для каждого администратора.
Настройте gpg-agent на рабочих станциях.
Экспортируйте публичные ключи на сервера в authorized_keys.
Документируйте процедуру ротации и инцидент-рукопись.

Ключевые числа и рекомендации

Рекомендуемый RSA keysize: 4096 бит.
Рекомендуемый срок валидности субключа: 1 год (1y).
Права на ~/.ssh/authorized_keys: 600.

Краткий глоссарий

GPG: реализация OpenPGP для шифрования и подписи.
Subkey (субключ): дополнительный ключ, привязанный к основному, с отдельными правами.
keygrip: внутренний идентификатор ключа в GnuPG.
gpg-agent: демон для хранения секретов и предоставления сокетов аутентификации.

Итог

Привязка SSH к GPG — практичный способ централизовать управление ключами и упростить администрирование. Процесс включает создание субключа с правами аутентификации, настройку gpg-agent и экспорт публичного ключа на сервер. Эта схема подходит для личных и командных рабочих процессов, но требует соблюдения политик безопасности и плановой ротации ключей.

Image credit: rivage via Unsplash. Все изменения и скриншоты — Ramces Red.