Поради щодо керування ключами SSH

Яку найкращу практику ви знайшли для керування великою кількістю SSH-клавіш?

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

Моя домашня мережа складається з мого ноутбука (ubuntu), двох робочих столів (ubuntu / fedora подвійне завантаження, fedora / windows dual boot) та медіа-системи (ubuntu). На роботі у мене є персональний ноутбук (який я використовую для роботи вдома), свій робочий стіл (Fedora), виробнича система (RHEL), а також ноутбук з windows (зітхання) та VM (fedora). Все добре поки що.

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

Але тепер з'являється Hadoop, великий кластер із 100+ систем, і це має більшу складність, більше користувачів та більше клавіш. Тепер мені потрібно керувати ключами.

(Мені потрібно уточнити. Я розробник програмного забезпечення, який консультується з клієнтом, який розгортає кластер Hadoop. Їм потрібно керувати ключами. До кластеру буде доступ багато людей, які потребують розміщення їх відкритих ключів у системі. Як резидент Linux savant, вони попросили мене про допомогу. Я порадив найняти системного адміністратора, але, поки вони не стануть, я допомагаю)

Коли мені потрібно опублікувати відкритий ключ у віддаленій системі, всі веб-сторінки "як" робити "пропонують або перезаписати (>) (знищити існуючі ключі), або додати (>>) (що добре, зберігає існуючі ключі) . Але я б подумав зберегти кожен відкритий ключ на машині призначення окремо, і поєднувати їх було б краще. Шукаю поради.

Яку найкращу практику ви знайшли для керування великою кількістю клавіш?

Дякую!

Редагувати. Одним аспектом є необхідність розміщення ключів у багатьох системах та супутнє CRUD (створення, читання, оновлення, видалення / відключення) для конкретних користувачів, а це означає, що потрібно мати можливість визначати, які ключі належать до яких користувачів.

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

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

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

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

Найпоширеніший спосіб - це використання загальних домашніх каталогів. Поставити NFS (або іншу мережеву файлову систему), встановити (або автоматизувати) всі системи.

Інший спосіб - скористатися новою функцією в ssh. Це називається директива конфігурації AuthorizedKeysCommand. В основному це команда, що sshd запускається кожного разу, коли потрібно шукати відкритий ключ. Команда просто записує відкритий ключ користувача, який запитується, на його STDOUT. Це в першу чергу використовується, коли у вас немає домашніх каталогів, але все ще є центральний сервер аутентифікації ( FreeIPA цим користується).

Звичайно, ви можете робити інші речі, такі як rsync cron для роботи /homeз центрального сервера. Але це не звичайна практика.

Коли мені потрібно опублікувати відкритий ключ у віддаленій системі, всі веб-сторінки "як" робити "пропонують або перезаписати (>) (знищити існуючі ключі), або додати (>>) (що добре, зберігає існуючі ключі) . Але я б подумав зберегти кожен відкритий ключ на машині призначення окремо, і поєднувати їх було б краще. Шукаю поради.а

я не бачу жодної переваги в зберіганні відкритих ключів як в .ssh/authorized_keysокремому файлі, так і в ньому.

якщо ви подивитеся на фактичні ключі, що зберігаються у файлі * санкціонованих_ ключів *, ви побачите, що вони вже містять читану людиною метаінформацію про походження ключа. наприклад, у відкритому ключі user@fooзазвичай є запис типу:

ssh-rsa AAAAB3Nza...LiPk== user@example.net

таким чином, дуже легко перевіряти / витягувати / видаляти певні ключі (прикріплені до певних користувачів) з файлу * санкціонованих_ ключів.

ідентифікатор користувача - це поле «коментар» у вільній формі, тому ви можете помістити туди будь-яку інформацію, яку ви вважаєте необхідною для ідентифікації даного ключа.

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

Останні OpenSSH дозволяють отримати ssh ключі від LDAP, див. "АвторизованіKeysCommand" на сторінці людини sshd_config . Особисто я віддаю перевагу сертифікатам OpenSSH, а не ключам, див. Http://blog.habets.pp.se/2011/07/OpenSSH-certificate . Ви можете керувати ключами з будь-яким менеджером конфігурації, як cfengine, ляльковий, шеф-кухар, сіль ...

Інший спосіб, який дуже просто реалізувати і дозволяє трохи більше гнучкості в плані додавання декількох користувачів, - це використовувати. https://userify.com/

Це дозволяє визначати різні групи серверів і мати ключі для різних користувачів, увімкнених або вимкнених для цих серверів.

Супер проста установка та управління.