Організуємо зберігання ключів OpenSSH на центральному сервері OpenLDAP

Архів номерів / 2007 / Випуск №9 (58) / Організуємо зберігання ключів OpenSSH на центральному сервері OpenLDAP

Віталій Банковський

Багато системних адміністраторів, які призначають паролі системним обліковим записам на серверах, а потім роздають їх користувачам (наприклад, програмістам та дизайнерам), стикаються з проблемою «розповзання» паролів серед користувачів. І в результаті неможливо визначити, які користувачі якого ресурсу мають доступ. До того ж, якщо використовуються паролі, їх необхідно міняти кожні кілька місяців, і при розсилці оновлених паролів існує небезпека їх «витікання».

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

Потім я деякий час використовував інструмент для централізованого управління серверами cfengine для копіювання ключів користувачів на сервер. Але при цьому виникла проблема, що через складність cfengine системні адміністратори 3-го та 4-го рівнів не могли керувати акредитацією користувачів.

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

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

Тому виникла ідея зберігання ключів у централізованій базі даних.

Після деякого дослідження було знайдено патч для OpenSSH, який дозволяє останньому звертатися до служби каталогів LDAP.

Кожен запис у каталозі складається з одного або декількох атрибутів і визначається унікальним ім'ям (DN – Distinguished Name), наприклад, cn = John Smith, ou = People, dc = example, dc = com.

Унікальне ім'я складається з декількох відносних унікальних імен (RDN – Relative Distinguished Name), розділених комою, які визначають положення запису в ієрархії каталогів LDAP, де на верхньому рівні, наприклад, знаходиться ім'я країни, де розташована компанія, потім назва компанії, підрозділ і нарешті список працівників.

Для простоти службу каталогів з демоном OpenLDAP називатимемо сервер LDAP, що включає:

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

Стаття була написана, виходячи з досвіду встановлення та експлуатації системи на Linux-дистрибутивах CentOS 4.1, CentOS 4.4, RedHat 7.3, Redhat 8.

Так як у такі дистрибутиви, як RedHat 7.3, RedHat 8.0, входять застарілі версії пакетів, мені довелося встановлювати їх з вихідних кодів.

До того ж використання пакетів із «рідних» сайтів дозволяє оперативно оновлювати сервери, не чекаючи оновлень відвиробників дистрибутивів, що, як на мене, є дуже важливою перевагою при використанні таких критичних додатків, як openLDAP.

Налаштування сертифікатів та TLS

Сервер OpenLDAP за умови компіляції підтримки TLS/SSL дозволяє створювати шифровані канали між демоном OpenLDAP та клієнтами.

Виходячи з цього, необхідно включити підтримку SSL/TLS у сервері OpenLDAP, згенерувати сертифікати та налаштувати клієнтів таким чином, щоб вони обривали з'єднання з сервером OpenLDAP у разі отримання підробленого сертифіката.

Тут слід пояснити, як працює перевірка. Під час перевірки сертифіката клієнт перевіряє організацію, яка підписала сертифікат. Якщо центр сертифікації (certificate authority, CA) невідомий клієнту (відсутня сертифікат самого CA), клієнт не довіряє цьому центру і, як наслідок, не довіряє сертифікату.

На даний момент існує близько 10-12 довірених центрів сертифікації (Equifax, Verisign тощо). Вартість підписання сертифікатів у цих центрах становить від 50 до 500 доларів.

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

Далі наведено кроки, які необхідно зробити для створення власного CA та підписати сертифікати.

До складу програмного пакету openSSL входить скрипт CA.sh, який спрощує створення сертифікатів.

Створити директорію, де зберігатимуться робочі файли сертифікатів:

mkdir certs; cd certs

Створити файли, необхідні для нашого власного CA:

В результаті буде створено каталог demoCA, де лежатиме сертифікат cacert.pem нашого CA.

Згенерувати запит на сертифікат:

openssl req -new -nodes -keyout newreq.pem -out newreq.pem

В результаті отримаємо файл newreq.pem, що складається із двох частин: приватний ключ сертифіката та запит (request) на сертифікат.

Під час підписання (наступний крок) OpenSSL використовує частину файлу, який містить запит (request) на сертифікат.

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

В результаті буде створено файл newcert.pem, який містить сертифікат нашого сервера OpenLDAP. Тут зверну вашу увагу на те, що хоча обидва файли розташовані на сервері OpenLDAP, при підключенні до сервера OpenLDAP клієнтам віддається вміст лише файлу newcert.pem.

Результуючі файли та їх описи наведено у таблиці 1.