Пересилання агента SSH чи копіювання ключа: що насправді витікає

Дві різні події називають витік ключа SSH, і вони вимагають різних реакцій. Автентифікація відкритим ключем надсилає відкритий ключ і підпис, зроблений закритим ключем, тому закритий ключ ніколи не є полем запиту. Пересилання агента викриває інше, бо віддалений хост, який дістає ваш пересланий агент, може попросити його підписати, жодного разу не тримаючи ключ. Якщо вважати це однією подією, вийде або безглузда заміна ключа, або делегування, яке продовжує працювати.

Вхід за відкритим ключем передає підпис, а не ключ

Обмін автентифікації несе відкритий ключ користувача і підпис над даними сеансу. Сервер перевіряє цей підпис ключем, якому вже довіряє, тому закрита половина може залишатися на клієнті через недовірену мережу. Оператор VPN, який спостерігає за тунелем, у будь-якому разі бачить зашифрований сеанс SSH.

Це описує протокол, а не надійність кожної кінцевої точки на шляху. Зберігайте перевірку ідентичності хоста недоторканою, бо клієнт, який приймає будь-який ключ хоста, відмовився від іншого контролю, ніж той, що обговорюється. Перехоплений сеанс і перехоплений ключ — окремі знахідки, і лише одна з них є втратою облікових даних. Тримайте обидві в окремих реченнях звіту.

ssh-keygen -lf ~/.ssh/id_ed25519.pub
ssh -o StrictHostKeyChecking=yes [email protected]

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

Пересилання агента делегує можливість підписувати

Коли пересилання ввімкнено, на віддаленому хості з'являється сокет, і локальний агент відповідає на запити, що надходять через нього. Будь-хто, хто може використовувати цей сокет під час сеансу, може автентифікуватися як ви на хостах, що приймають завантажені ідентичності. Жоден закритий ключ не перетинає мережу, щоб це працювало.

Викриттям є можливість, а не файл. Тому пересилання належить названому завданню та названому хосту, а не кожному з'єднанню ноутбука. Проміжний хост, який передає з'єднання без пересланого агента, зазвичай повністю знімає потребу.

ssh-add -l
ssh -o ForwardAgent=no [email protected]
ssh -J [email protected] [email protected]

Перша перелічує, які ідентичності агент тримає зараз, що варто знати перед передаванням його сокета іншій машині. Друга підключається без делегування. Третя показує схему проміжного хоста, яка часто повністю замінює пересилання.

Виберіть реакцію за наявними доказами

Ідентичність для підпису, яку вважають викритою, потребує процесу заміни й відкликання, а також вилучення її прийняття із сервісів, які їй довіряли. Видалення копії на ноутбуці залишає кожну іншу копію недоторканою. Почніть із сервісів, потім приберіть клієнтів.

Тимчасова проблема делегування вужча. Припиніть пересилання, яке не було потрібне, і разом із власником інциденту перегляньте, які сеанси та ідентичності воно охоплювало. Заміна ключа може послідувати, але це вирішують докази, а не занепокоєння.

Відсутність спостережуваного експорту доводить лише те, що механізм, якого ви боялися, не з'явився. Вона нічого не каже про те, що ще міг зробити хост на іншому кінці цього сокета.

Тримайте засоби контролю окремо у звіті

Захищайте закритий матеріал, обмежуйте, хто може попросити його підписати, підтримуйте перевірену ідентичність іншої сторони. Це три засоби, які підсилюють один одного, і жоден із них не замінює інший, коли ви пояснюєте, що сталося.

Скомпрометований ноутбук або привілейована програма на ньому — третій випадок із значно ширшим радіусом ураження. Зміна маршруту VPN це не вирішує і не відновлює довіру до ключа, який міг бути прочитаний із диска.

Запишіть, якому компоненту довіряли, чи було ввімкнено пересилання і що насправді спостерігалося. Саме цей запис робить наступне рішення обґрунтованим, а не здогадом про значення витоку.