Использовать определенный перенаправленный ключ от SSH-агента?

Допустим, у меня есть ключ для Github и другие ключи. Я добавил много ключей к моему ssh-агенту ( ssh-add -Lвозвращает много строк) на моем домашнем компьютере A. В моем, .ssh/configя установил, какой ключ использовать с каким хостом, например,

ssh -T -vvv git@github.com 2>&1 | grep Offering

дает

debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.github

Как и ожидалось, предлагается только один ключ. Но затем, подключившись к некоторому хосту B ForwardAgent yesи повторив ту же команду, я получаю

debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.linode2
debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.helium
debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.github

значит, он пробует все мои ключи. Это проблематично, поскольку перед возвратом серверов можно попробовать только ограниченное количество ключей Too many authentication failures. Поэтому я попытался изменить .ssh/configна хосте B, чтобы включить

Host github.com
  IdentityFile /Users/doxna/.ssh/id_rsa.github
  IdentitiesOnly yes

но тогда я не получаю никаких ключевых предложений, а скорее

debug2: key: /Users/doxna/.ssh/id_rsa.github ((nil))

что, по-моему, означает, что ключ не был найден (?) И, в конце концов, ключ находится на моем домашнем компьютере A, а не на хосте B, поэтому вопрос в том, как обратиться к нему на хосте B? Надеюсь, мне удалось объяснить вопрос.

ssh ssh-agent danmichaelo
источник

Ответы:

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

На хосте B вы можете извлечь открытый ключ из агента, набрав ssh-add -L | grep /Users/doxna/.ssh/id_rsa.github > ~/.ssh/id_rsa.github.pubи затем указать на этот файл из~/.ssh/config

kasperd
источник

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

Акостадинов

@akostadinov Правда. Если вы указываете sshна файл открытого ключа без связанного файла закрытого ключа, он должен просто прочитать открытый ключ из файла и заставить агента использовать соответствующий закрытый ключ для генерации подписи.

kasperd

Это эффективно сохраняет ваш ключ на хосте B! Посмотрите ответ ниже @ mc0e для решения, которое не сохраняет ключ на сервере.

Питт

@ Питт Нет, это не так. Он хранит только открытый ключ. И это не проблема, поскольку открытый ключ никогда не должен был храниться в секрете. Переадресация агента дает хосту доступ к использованию ключа, пока переадресация агента включена, но агент никогда никуда не отправит секретный ключ.

Касперд

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

mc0e

Хороший ответ от @Kasperd, но учтите также, что если хост B скомпрометирован или если вы не доверяете всем, у кого есть привилегии root, вы все равно подвергаете все свои ключи злоупотреблению до тех пор, пока вы вошли в систему. на этом хосте.

Поэтому лучшим подходом может быть перенаправление доступа только к тем ключам, которые вам нужны. Может быть, попробуйте ssh-agent-filterв репозиториях Debian / Ubuntu или из github .

РЕДАКТИРОВАТЬ: Я остановился, ssh-identа не ssh-agent-filterна выборочной пересылке ключей, хотя это не так гладко, как можно надеяться.

mc0e
источник

Из комментария @ kasperd к его ответу: «это не так. Он хранит только открытый ключ. И это не проблема, так как ожидалось, что открытый ключ никогда не будет храниться в секрете. Переадресация агента дает хосту доступ к используйте ключ, пока существует переадресация агента, но агент никогда никуда не отправит секретный ключ "

Bdoserror

@Bdoserror Как пользователь root, вы можете злоупотреблять соединением ssh-agent, когда связанный пользователь вошел в систему. Вы просто копируете SSH_*переменные окружения и входите туда, куда вы хотите перейти, используя ключ, несмотря на то, что у вас нет действительной копии.

mc0e

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

Восстановить Монику

@ marc-lehmann перечитайте то, что я написал. Если вы перенаправите ключи, они будут открыты, но вы можете ограничить, какие ключи будут перенаправлены.

mc0e

Я перехожу на то, что вы написали - пожалуйста, обращайтесь к сути наших комментариев, а не к человеку. Проблема в том, что ваш ответ просто неправильный, так как он предполагает, что, когда вы пишете, ключи «перенаправляются» на удаленный хост. Ничего подобного не происходит, и сами ключи не открываются.

Восстановите Монику