1

Я использую ключ 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 ответ1

2

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

  • Закрытые ключи никогда не отправляются никуда. Переадресация агента использует противоположный механизм: клиенты 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 с других терминалов.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .