Краща система управління ключами ssh? [зачинено]

У мене є декілька клієнтських комп'ютерів (тобто ноутбуки, настільні комп'ютери тощо), і я підключаюсь до декількох серверних машин, якими я керую, і я входжу в них все через SSH. Я можу уявити кілька схем управління ключами ssh, які мали б сенс, і мені цікаво, що роблять інші.

Варіант 1. Один глобальний державний / приватний ключ.

Я б створив один відкритий / приватний ключ, і ставлю приватний ключ на кожній клієнтській машині, а відкритий - на кожній серверній машині.

Варіант 2: одна клавіша на сервері.

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

Варіант 3: одна клавіатура на клієнтській машині.

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

Варіант 4: Один пара клавіш на пару клієнт / сервер

Повністю за бортом?

Що з них найкраще? Чи є інші варіанти? Які критерії ви використовуєте для оцінки правильної конфігурації?

Я використовую Варіант 3: Одна клавіша на клієнтській машині, і це має для мене найбільш сенс. Ось деякі причини:

• Якщо клієнт піддається злому, то цей ключ (і лише той ключ) потрібно видалити з серверів.
• Це досить гнучко, щоб вирішити, до чого я можу отримати доступ, звідки, не надаючи бланк доступу на всі сервери від усіх клієнтів.
• Дуже зручно. Існує лише 1 ключ для ssh-add, без плутанини.
• Легко налаштувати та адмініструвати через Варіант 4

Варіант 4 приємний, але це занадто багато роботи. Варіант 3 приносить вам 98% там із набагато меншими клопотами.

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

Тепер, коли це сказано, я працюю з робочих станцій Linux майже виключно, тому у мене є ключ USB, який налаштовується за допомогою шифрування LUKS, і мій менеджер вікон X11 разом з демоном HAL виявляє зашифрований диск LUKS і запитує про парольну фразу розшифровки, коли він вставляється та намагається бути змонтованим. Зберігаючи це на зашифрованому диску, як я це роблю, я ніколи не зберігаю свої SSH ключі на жодній робочій станції.

Потім у моєму ~/.ssh/configфайлі є така конфігурація :

Host *
    Protocol 2
    IdentityFile %d/.ssh/keys.d/id_rsa.%l
    IdentityFile %d/.ssh/keys.d/id_dsa.%l
    IdentityFile %d/.ssh/keys.d/%u@%l

% D перекладається бути домашній каталог користувача з допомогою OpenSSH і в ~ / .ssh каталогу Я створив keys.d в якості символічного посилання на шлях до каталогу на зашифрованому диску USB , коли він правильно встановлений.

% Л вираз перекладається як локальний клієнтські машини ім'я хоста і % U будуть переведені на ім'я користувача локального клієнта.

Ця конфігурація дозволяє SSH шукати ключ за допомогою 3 різних виразів. Наприклад, якщо ім'я мого локального клієнта було jdoeі ім'я моєї локальної клієнтської машини, examplehostвоно виглядатиме в наступному порядку, поки не знайде ключ, який існував і не був прийнятий віддаленим сервером.

/home/jdoe/.ssh/keys.d/id_rsa.examplehost
/home/jdoe/.ssh/keys.d/id_dsa.examplehost
/home/jdoe/.ssh/keys.d/jdoe@examplehost

Ви навіть можете використовувати вираз % r, щоб шукати ключ, специфічний для імені віддаленого сервера, або % h для імені хоста віддаленого сервера так само, як використовувались % u та % l .

Оновлення: Тепер я фактично використовую gnuPG-агент GnuPG із сумісністю ssh-агент, щоб просто прочитати та використовувати ключ автентифікації зі своєї смарт-картки OpenPGP v2.

Я би усунув обидва варіанти 1 (з яких я підозрюю, що один повинен був бути варіантом 2 ;-), оскільки приватні ключі є конфіденційними даними, і є сенс зберігати їх у якомога менше місцях. Я особисто ніколи не копіював би приватний ключ з одного комп'ютера на інший (або навіть з одного файлу в інший на одному комп’ютері), за винятком, можливо, для створення резервних копій. Хоча на відміну від більшості ключів шифрування, якщо ключ SSH загубиться, це ще не кінець світу (просто створіть новий, ви не втратите жодних даних).

Варіант 3 і використовувати щось на зразок Лялькового для керування ключами.

Варіант 3.

Це також дозволяє контролювати, до яких серверів клієнт може отримати доступ. наприклад, якщо клієнту X потрібен доступ до серверів A і B, але C або D, ви копіюєте його відкритим ключем лише для цих хостів.