OpenSSH з відкритими ключами від бази даних


14

Чи можливо отримати відкриті ключі з бази даних замість файлу санкціонованих_ ключів?

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


1
Я використовую для цього маріонетку
Метт Сіммонс

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

Відповіді:


16

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

Так,

  1. Перш за все, RedHat (та його варіанти) мають підтримуваний патч для OpenSSH, який додає AuthorizedKeysCommandта AuthorizedKeysCommandRunAsпараметри. Виправлення було об'єднано вище за течією в openssh 6.2. Для цитування зі сторінки man :

    AuthorizedKeysCommand

    Визначає програму, яка використовуватиметься для пошуку відкритих ключів користувача. Програма буде викликати своїм першим аргументом ім'я авторизованого користувача та повинно створювати на стандартних вихідних рядках AuthorizedKeys (див. AUTHORIZED_KEYS у sshd (8)). За замовчуванням (або якщо встановлено порожній рядок) не існує запуску AuthorizedKeysCommand. Якщо AuthorizedKeysCommand не успішно авторизує користувача, авторизація потрапляє до AuthorizedKeysFile. Зауважте, що ця опція діє лише з увімкненою PubkeyAuthentication.

    AuthorizedKeysCommandRunAs

    Вказує користувача, під чиїм обліковим записом запускається AuthorizedKeysCommand. Порожній рядок (значення за замовчуванням) означає, що використовується користувач, який авторизується.

    У своїх експериментах сьогодні ввечері я виявив, що поза межами цієї програми це не працює через політику SELinux за замовчуванням. Ви можете подолати це, вимкнувши примусове виконання SELinux за допомогою setenforce 0. Оскільки повернення SELinux - це, мабуть, погана ідея, натомість ви можете створити правильну політику. У моєму випадку це було так само просто, як спроба ввійти в систему за допомогою AuthorizedKeysCommandналаштування, /etc/ssh/sshd_configа потім використовувати audit2allow -a -M local && semodule -i local.pp. Це, в основному, переглядає журнали аудиту та знаходить речі, які їх запобігли, і створює для них винятки. Якщо у вас, ймовірно, є інші речі, які можуть потрапити до списку, ви, мабуть, дізнаєтесь більше про те, audit2allowщоб переконатися, що ви отримаєте нові правила правильно.

  2. Є інші різні (можливо, менш перевірені та надійні) патчі, щоб додати подібну функціональність. Наприклад, існує, openssh-script-auth . Ви також можете знайти виправлення, яке використовував RedHat, і застосувати його безпосередньо. Швидкий наліт Googling розкриває https://launchpadlibrarian.net/89063205/openssh-5.3p1-authorized-keys-command.patch та https://launchpadlibrarian.net/105938151/openssh-authorized-keys-command.patch, які є на основі версій RH, але які були оновлені для новіших версій OpenSSH.

  3. Patch OpenSSH виконувати пошук ключів безпосередньо з якогось магазину (наприклад, як GitHub та CodeBaseHQ та інші). GitHub не відкрив цей патч, наскільки мені відомо, але я знаю, що раніше я натрапляв на версії для пошуку ключів MySQL та PostgreSQL. Я намагався їх знайти ще раз, але не пощастило.

  4. Існує також кілька варіантів на основі FUSE. Наприклад, є LPKFuse, який дозволяє обслуговувати відкриті ключі від LDAP, змінюючи AuthorizedKeysFileрозташування на один у файловій системі LPKFuse. LPKFuse FS створює віртуальні файли, вміст яких підтримується полями з сервера каталогів.


Загалом, я думаю, що варіант №1 є на сьогодні найкращим, оскільки він офіційно підтримується RedHat. Крім того, він дозволяє вам вводити будь-яку логіку в цей сценарій (включаючи розмову з базою даних) будь-якою мовою.


Re: # 1 приємна знахідка !! Я сподіваюся, що це буде вгору за течією, це було б зручно в ESXi.
Джейсон Тан

@JasonTan: AuthorizedKeysCommand пішов вгору за течією в 6.2sh. Я також оновив відповідь, щоб це відобразити.
Bluewind

Чудова відповідь, варіант 1 був саме тим, що я шукав.
Шейн Кілкеллі

3

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

Також, можливо, ви захочете побачити це питання: Система розповсюдження відкритих ключів SSH


1

Я вважаю, що в нових версіях opensh ви можете зберігати ключі у записі LDAP користувачів. Якщо ви вже використовуєте LDAP або AD для управління обліковим записом, ви повинні мати можливість використовувати його і для управління ключами.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.