Аутентифікація ключа SSH з кількома комп'ютерами


21

Я читав про автентифікацію ключів SSH та налаштовував її на своїх трьох комп'ютерах вдома.

У мене є один основний комп’ютер, називають його «А» та два інших, називаємо їх «В» і «С».

Тепер, виходячи з прочитаної документації, я би запустив ssh-keygen на B і C і поставив відкриті ключі на комп'ютер A, припускаючи, що я завжди буду SSH в комп'ютер A, якщо я на B або C.

Але, я думаю, що приклади документації, які я прочитав, передбачають, що лише 1 домашній комп'ютер буде використовуватися з дозволом сказати якийсь інший зовнішній комп'ютер. У моїй ситуації чи є сенс просто запустити ssh-keygen на одному комп’ютері та скопіювати файли на інші? Таким чином мені потрібно створити резервну копію одного набору ключів? А коли я входжу на зовнішній комп'ютер, мені потрібно встановити його лише з 1 набору ключів, а не проти налаштування його на всіх трьох комп’ютерах.

Це має сенс? Будь-які недоліки чи застереження щодо розгляду?

Спасибі.

Відповіді:


29

Можна теоретично робити обидва способи, але кожен з них має свої переваги та недоліки:

Ви дійсно можете створити лише 1 ключ, сказати, що він "ваш" (як людина), закріпити його десь і скопіювати на будь-який комп'ютер, який ви використовуєте. Перевага полягає в тому, що ви можете підключитися до A звідки завгодно, поки ви маєте приватний ключ SSH. Недолік полягає в тому, що якщо ви копіюєте свій приватний ключ з місця в інше, незалежно від способу, ви збільшуєте ризик того, що його прочитає хтось, хто підслуховує з'єднання. Гірше, що якщо комп'ютер C викрадений, вам доведеться відновити новий ключ на всіх комп'ютерах, які використовують цей ключ, і розповсюдити новий.

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

Якщо, наприклад, ви мали б подарувати комп’ютер С своєму братові / сестрі / дружині / чоловікові / другові / собаці, або злодію (без вашого погодження), вам просто доведеться вийняти ключ з '' дозволених_кіїв '' A файл.

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


Ви не можете розшифрувати потік ssh за допомогою приватного ключа клієнта, і залежно від налаштувань сервера ви також не можете розшифрувати його приватним ключем сервера. zurlinux.com/?p=1772
Dan Merillat

Це правильно, і це не те, що я мав на увазі. Я мав на увазі, якщо у вас вкрадеться приватний ключ, ви можете використовувати його для підключення до комп'ютера A з будь-якого місця. Це можна зменшити, додавши FROM = "<IP>" на початку рядка дозволених ключів. (див. сторінку ssh man)
mveroone

після його копіювання мені довелося вставити свій пароль, щоб використовувати його на іншому комп’ютері, я думаю, що це якась безпека принаймні :)
OZZIE

3

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

Kwaio правильно вказує, що це збільшує ризик пошкодження ваших ключів. Одним з можливих рішень було б розділити приватний та відкритий компоненти. Так:

  • Усі файли комп'ютерів мають ваш відкритий ключ у файлі санкціонованих ключів.
  • Ви зберігаєте 2 копії свого приватного ключа; один - у USB-накопичувачі на шиї (для використання ssh для доступу до іншого комп'ютера), а другий - у USB-накопичувачі в сейфі десь (про всяк випадок, коли ви втратите першу копію).

Якщо хтось із ваших комп'ютерів викрадений або ваш відкритий ключ іншим чином порушений - ну це просто відкритий ключ, і що.

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

HTH.


2
Гаразд, але що таке HTH?
mikeserv

3
HTH = Надія, яка допомагає.
АЛАН ВАРД

1
Було б розумно зазначити, що якщо ви помістите приватний ключ у флешку, було б розумно зробити його приватним ключем, захищеним паролем. Невідповідність необхідності вводити парольну фразу кожного разу можна пом'якшити за допомогою агента (патент на Windows, ssh-агент на Linux)
mveroone
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.