Как настроить переадресацию SSH-ключа с помощью gpg-agent?

Я использую ключ SSH на Yubikey, поэтому я использую gpg-agent вместо ssh-agent. Это в принципе работает нормально, за исключением стандартных причуд (время от времени приходится убивать scdaemon).

Однако переадресация ключа SSH, похоже, не работает.

Вот моя установка:

Office (RedHat 7.6) со вставленным Yubikey, используя openssh и gpg-agent -> destination: works.

Home (Windows 10) со вставленным Yubikey, используя Putty и gpg-agent -> Office: работает

Домой -> Офис (gpg-agent) -> пункт назначения: сообщение об ошибке "агент отказался от операции".

Домой -> Офис (ssh-agent) -> пункт назначения: работает (на самом деле я не проверял это, но настраивал его много раз).

Я включил переадресацию агента на соединение Putty в Home, а также в /etc/ssh/sshd_config в Office.

Я что-то не так делаю, или gpg-agent не поддерживает переадресацию агента, когда он является посредником?

Источник

1 ответ

Решение

Вы несколько ошибаетесь по поводу того, как работает переадресация агента:

  • Закрытые ключи никогда не отправляются никуда. Переадресация агента использует противоположный механизм: клиенты SSH, работающие в удаленной системе, будут отправлять запросы на подпись обратно в вашу локальную систему, где локальный gpg-agent выполняет операцию и отправляет результат обратно.

    (Кроме того, невозможно извлечь закрытый ключ из вашей смарт-карты, поэтому даже ваш местный gpg-агент не имеет настоящего закрытого ключа.)

  • Не существует такого понятия, как "посредник". Единственным промежуточным программным обеспечением являются локальный клиент SSH и удаленный демон sshd. Удаленная система не запускает никаких ssh-агентов или gpg-агентов для обработки пересылки, и если они уже были запущены, они остаются полностью неиспользованными и не знают об этом соединении.

Когда вы находитесь дома и подключаетесь (например) из HOME в OFFICE с включенной переадресацией агента, вы должны увидеть $SSH_AUTH_SOCK, указывающий на сокет, принадлежащий процессу sshd, который принял ваш логин, а не на какой-либо отдельный процесс агента. (Вы можете проверить с sudo lsof $SSH_AUTH_SOCK.)

Если ваша проверка показывает, что удаленная система фактически указала $SSH_AUTH_SOCK на свой собственный процесс ssh-agent или gpg-agent, это проблема: либо сервер не принял запрос перенаправления агента, либо ваши сценарии входа в систему (~/.profile и т. д.) излишне перезаписывают переменную окружения.

Когда вы затем пытаетесь подключиться из OFFICE к еще одному серверу, клиент ssh в OFFICE отправляет запрос на подпись через этот сокет непосредственно вашему локальному агенту, в основном неотличимый от локального запроса. (Локальный агент видит, что только локальный ssh- клиент делает этот запрос, поэтому у него нет возможности "не поддерживать" переадресацию агента.)

Если локальный агент отклоняет этот запрос, процесс устранения неполадок в основном такой же, как и при обычных прямых соединениях: если это gpg-agent, убедитесь, что у вас установлено значение $GPG_TTY; бежать gpg-connect-agent updatestartuptty /bye при необходимости перед установкой начального соединения будьте осторожны, чтобы не использовать команды gpg с других терминалов.

Источник
Другие вопросы по тегам