Використовувати певний перенаправлений ключ від SSH-агента?


30

Скажімо, у мене є ключ від Github разом з іншими ключами. Я додав багато ключів до мого агента ssh ( ssh-add -Lповертає безліч рядків) на своєму домашньому комп’ютері А. У своєму моєму режимі .ssh/configя встановив, який ключ використовувати з яким хостом, наприклад,

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

дає

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

Пропонується лише один ключ, як очікувалося. Але потім ssh-ing до якогось хоста 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? Сподіваюся, мені вдалося пояснити питання.

Відповіді:


28

Ви отримали правильну ідею. Єдина частина, на яку ви не бракуєте, - це те, що файл, на який вказують, IdentityFileповинен існувати. При цьому не потрібно містити приватний ключ, достатньо мати лише відкритий ключ.

На хості B ви можете дістати відкритий ключ з агента, ввівши, ssh-add -L | grep /Users/doxna/.ssh/id_rsa.github > ~/.ssh/id_rsa.github.pubа потім вказати на цей файл з~/.ssh/config


FYI назва відкритого ключа не має значення. Він вибере належний ключ від агента на основі вмісту.
акостадінов

@akostadinov Правда. Якщо ви вказуєте sshна файл відкритого ключа, не пов’язаний з файлом приватного ключа, він повинен просто прочитати відкритий ключ з файлу і змусити агента використовувати відповідний приватний ключ для створення підпису.
kasperd

Це ефективно економить ваш ключ на хості B! Дивіться нижче відповідь від @ mc0e для рішення, яке не зберігає ключ на сервері.
Пітт

2
@Pitt Ні, це не так. Він зберігає лише відкритий ключ. І це не проблема, оскільки ніколи не очікувалося, що відкритий ключ буде триматися в таємниці. Переадресація агента надає хосту доступ до використання ключа доти, доки переадресація агента знаходиться на місці, але агент ніколи не надсилатиме секретний ключ кудись.
kasperd

@kasperd вам не потрібна фактична копія приватного ключа, коли ви маєте пряме з'єднання з користувальницьким агентом за допомогою ключа. Як root ви можете отримати доступ до з'єднань з агентами інших зареєстрованих користувачів.
mc0e

5

Приємна відповідь від @Kasperd, але зауважте також, що якщо Host B піддається злому, або якщо ви не довіряєте всім, хто має привілеї root, там ви все-таки піддаєте зловживання всіма вашими ключами, поки ви зареєстровані. в цьому хості.

Тож кращим підходом може бути лише переадресація доступу до потрібних вам ключів. Можливо, спробуйте, ssh-agent-filterщо знаходиться в сховищах debian / Ubuntu або з github .

EDIT: Я зупинився на вибірковому, ssh-identа не ssh-agent-filterна переадресації ключів, хоча це не так гладко, як можна було б сподіватися.


1
З коментаря @ kasperd до його відповіді: "це не так. Він зберігає лише відкритий ключ. І це не проблема, оскільки очікується, що відкритий ключ не буде таємним в першу чергу. Переадресація агента надає хосту доступ до використовуйте ключ доти, поки переадресація агента знаходиться на місці, але агент ніколи не надсилатиме секретний ключ кудись "
Bdoserror

1
@Bdoserror Як root, ви можете зловживати з'єднанням ssh-agent під час входу асоційованого користувача. Ви просто скопіюєте SSH_*змінні середовища та увійдете в те місце, куди ви хочете скористатися ключем, незважаючи на те, що ніколи не маєте фактичної копії.
mc0e

Для уточнення: ця відповідь справді неправильна - хоча сценарій зловживання з mc0e справжній, це не має нічого спільного із збереженням відкритого ключа - якщо проміжний хост порушений, підключення вашого агента може використовуватися для аутентифікації з вашим приватним ключем, незалежно. чи зберігаєте ви відкритий ключ на проміжному хості чи ні. Ваш приватний ключ не буде порушений, а збереження відкритого ключа не полегшить роботу, оскільки будь-який зловмисник, який має з'єднання з агентом, може просто попросити його відкритими ключами.
Відновіть Моніку

@ marc-lehmann перечитав те, що я написав. Якщо ви переадресуєте ключі, вони будуть відкриті, але ви можете обмежити, які ключі будуть переадресовані.
mc0e

Я ступаю те, що ви написали - будь ласка, зверніться до суті наших коментарів, а не до людини. Проблема полягає в тому, що ваша відповідь просто неправильна, оскільки передбачає, що ви пишете, що ключі "пересилаються" на віддалений хост. Нічого подібного не відбувається, а самі ключі не оголюються.
Відновіть Моніку
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.