Использование директивы IdentityFile в ssh_config, когда используется AgentForwarding


15

Можно ли указать перенаправленные ключи с помощью директивы IdentityFile в .ssh / config?

Я столкнулся с этой причудой, когда пытался развернуть некоторый код через Capistrano / GIT на нашем производственном сервере. И мой личный, и мой рабочий ключи GIT всегда загружаются в мой агент SSH, и так получилось, что мой личный ключ был добавлен в агент первым. Я использую переадресацию агентов при развертывании с Capistrano, поэтому, когда хост пытался аутентифицировать операцию `git pull`, он завершился ошибкой со следующей ошибкой:

ОШИБКА: доступ к «некоторому репо» запрещен «вашему пользователю».

потому что он пытался аутентифицироваться с использованием моего личного ключа git, прежде чем пытаться использовать соответствующий ключ (который появился позже в агенте ssh), и предполагал, что у меня есть доступ к иностранному репо, к которому у меня нет разрешения. Потенциально я могу просто предоставить своему личному пользователю доступ к каждому рабочему репо, но на своем локальном компьютере я могу обойти эту проблему, определив пользовательские домены в .ssh / config следующим образом:

Хост personal.github.com
Hostname github.com
Пользователь мерзавец
IdentityFile ~ / .ssh / some_key

Хост work.github.com Имя
хоста github.com
Пользователь git
IdentityFile ~ / .ssh / some_other_key

и таким образом мерзавец никогда не запутывается. Можно ли создать правила .ssh / config для переадресованных ключей на моих производственных ящиках, чтобы они всегда знали, какой ключ использовать при извлечении нового кода? В основном я хочу иметь возможность сделать:

Хост work.github.com Имя
хоста github.com
Пользователь git
IdentityFile some_forwarded_key

Благодарность!

Ответы:


22

Вы можете использовать открытую часть ключа, чтобы указать, какой закрытый ключ вы хотите использовать от перенаправленного агента. Это требует создания дополнительного файла (публичной части ключа) на любых «промежуточных» машинах (машинах, на которые вы пересылаете свой локальный ssh-агент ).

  1. Сделайте так, чтобы промежуточная машина имела копию открытой части желаемого ключа в удобном месте (например ~/.ssh/some_other_key.pub).

    С любой машины, у которой уже есть открытая часть ключа:

    scp some_other_key.pub intermediate:.ssh/
    

    или на промежуточной машине:

    ssh-add -L | grep something_unique > ~/.ssh/some_other_key.pub
    

    Вы можете отредактировать завершающую часть «комментария» открытого ключа, чтобы лучше определить происхождение / владельца / цель ключа (или попытаться скрыть то же самое).

  2. Используйте путь к указанному выше файлу открытого ключа с помощью -iили IdentityFile.

  3. Вам также может понадобиться использовать IdentitiesOnly yes.ssh/configили -o), чтобы ssh не пытался предложить какие-либо дополнительные идентификаторы от вашего перенаправленного агента.


Это единственное, что сработало для меня из 10 других решений.
Трейси Фу

1
Играя с этим, я понял, что если вы поместите открытый ключ, связанный с закрытым ключом, который вы хотите использовать, в ~ / .ssh / id_rsa.pub на промежуточном компьютере, он будет использоваться по умолчанию, нет необходимости в какой-либо конфигурации в ~ / .ssh / конфигурации.
bschlueter

Спасибо Крис и bschlueter! Теперь я соединяюсь с: ssh someserver -t "ssh-add -L | grepthing_unique> ~ / .ssh / id_rsa.pub; cd some / other / folder; bash --login"
blablabla

Когда я пытаюсь это сделать, ssh -v -T ...сервер принимает открытый ключ, но затем ssh сообщает, No such identity: /home/name/.ssh/id_rsa: No such file or directoryчто аутентификация не проходит. У меня включен ForwardAgent во всех моих конфигах. В чем может быть проблема?
Ларс Нистрем
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.