Централізована система управління ключами SSH?

27

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

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

Хтось знає про таку систему - комерційну чи відкриту?

ПРИМІТКА. Для уточнення нам потрібне управління ключами для досить великої кількості хмарних серверів (схожих на EC2) та невеликої кількості користувачів сервісу. Я думаю, що LDAP + виправлення, що запропоновано нижче, може бути шляхом.

ssh cloud keys

— SyRenity
джерело

7

Хіба тільки я вважаю, що "приватні ключі та хмара" схожі на "пити та їздити". Обидва розважаються окремо, але ніколи не йдуть разом.

— mailq

1

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

— voretaq7

Привіт. Саме - те, що ми шукаємо.

— SyRenity

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

— Том Х

Userify охоплює те, що ви шукаєте (див. Serverfault.com/questions/647797/… )

— Becker

8

Існує маса способів зробити це. Пам'ять ключів LDAP було згадано пару разів, і я це зробив, і він працює, наскільки це робиться. Однак у LDAP є власні цікавості управління, які потребують певного навчання.

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

— жіночий
джерело

Такий підхід, безумовно, хороший, і як зазначає Womble, він має перевагу в тому, що сервери залишаються та працюють (і доступні) у випадку, коли LDAP знижується - кожна система, що підтримується LDAP, повинна (смію сказати, повинна ) принаймні один користувач, чиї клавіші висунуті так, як описує Womble. Мінус полягає в тому, що вам потрібно виконати конфігурацію, щоб скасувати авторизацію користувачів. Не проблема для "екстреного облікового запису" лише з кількома авторизованими користувачами. Більша проблема для великої кількості акаунтів :)

— voretaq7,

1

Ви дійсно повинні мати спосіб запускати масові запуски конфігурацій, так що не слід робити це для зміни облікового запису.

— живіт

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

— voretaq7

1

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

— живіт

2

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

— SyRenity

23

Пари ключів повинні бути створені користувачем.

Користувач зберігає приватну половину - ви ніколи її не бачите. Якщо у вас є чийсь приватний ключ у формі, де ви можете його читати / використовувати, ви робите неправильну безпеку.

Публічна половина надається вам (за будь-яким механізмом, який ви хочете: веб-форма, електронна пошта, передайте мені-на-компакт-диску), яку ви хочете централізувати, як тільки захочете. Деякі місця зберігають відкриті ключі в LDAP. Інші виштовхують authorized_keysфайли за допомогою їх системи розгортання.

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

На кожному з наших сайтів є пара серверів LDAP, синхронізована з нашим майстром з реплікацією LDAP, яка зберігає дані послідовними (і доступними) у кожному місці.

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

— voretaq7
джерело

Отже, ви пропонуєте використовувати інфраструктуру LDAP, з виправленим OpenSSH, який буде працювати з LDAP? Наскільки добре цей масштаб у виробництві? Чи може він підтримувати велику кількість машин? Нам потрібно підтримувати лише невелику кількість користувачів сервісу.

— SyRenity

1

@SyRenity: LDAP підтримує реплікацію та кластеризацію, тому вона дуже добре масштабується

— Хуберт Каріо

@SyRenity Теоретично ви можете підтримувати необмежену кількість машин у необмеженій кількості місць (подумайте "Дійсно велике розгортання Active Directory" - AD в основному є LDAP з деякими модними аксесуарами). Для користувачів сервісу моя пропозиція полягає в їх стандартизації всієї середовища і виштовхнути стандартизовані /etc/passwdі /etc/groupфайлів (дозволяє машинам працювати нормально , і пов'язані з ними послуги для запуску / запуску , навіть якщо LDAP не доступний)

— voretaq7

@ voretaq7 Що означає, що користувачі служби будуть управлятися окремо від LDAP, через управління конфігурацією?

— SyRenity

@SyRenity так - і ще важливіше для сервісів, які ними користуються, якщо LDAP знижений . Плануйте невдачі, або у вас виникнуть катастрофи.

— voretaq7

9

Клавіатури не слід генерувати ніде, а на комп'ютері кожного користувача. Приватні ключі названі як такі з причини.

При цьому я можу побачити випадок використання для якогось централізованого сховища відкритих ключів користувачів. Одним із варіантів було б зберігання відкритих ключів у OpenLDAP - останні версії OpenSSH можуть читати ключі з LDAP.

— EEAA
джерело

2

Чи є речі LDAP-відкритого ключа в основному OpenSSH? Я знаю лише патч LPK (на який я можу поручитися - він чудово працює). Також +1 для збереження приватних ключів.

— voretaq7

@ voretaq7 Напевно, я чув, що він об'єднується в основну лінію, але я ще цього не підтвердив. Ми ділимось домашніми каталогами через NFS, так що ми піклуємося про наше ключове розповсюдження для нас.

— EEAA

+1 добре, я цього не знав. це врятує мені купу клопоту. ось у моєму списку речей, на які слід звернути увагу.

— Том H

1

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

Для тих, хто шукає рішення, крім LDAP, я просто знайшов проект "SKM": https://sites.google.com/site/jeromeboismartel/code-s-corner/ssh-key-management-with-skimp

— fukawi2
джерело

1

Існує багато чудових комерційних та відкритих рішень, таких як Userify [1] (де я працюю), Universal Key Manager [2], SSH Key Box [3] і т. Д. Це залежить від ваших потреб і якщо ви шукаючи те, що централізує управління при децентралізації роботи (щоб ваші сервери не покладалися на центральну владу для входу ... у цьому випадку ви не зможете увійти в жоден із своїх серверів, якщо, скажімо, ваш Сервер LDAP не працює!)

Дивіться також цю схильну дискусію:

https://www.slant.co/topics/8010/~managers-for-ssh-keys

— Джеймісон Бекер
джерело