Для полного порядка в корпоративной сети нужно, чтобы все сервисы аутентифицировались через одно место :) Каждый, как говорится, понял в меру своей испорченности.
Делается это следующим образом. Как многие знают, сегодня считается моветоном делать самостоятельные проверки паролей, групп и прочего. Давным давно уже изобрели единый центр проверок PAM. Даже утилита login, которая запускается, когда Вы коннектитесь к консоли, проверяет не сама, а отдает эту задачу "на аутсурс" PAM'у. Соответственно и OpenSSH сам не проверяет пароли.
Изначально у нас есть PAM-модуль для проверки через passwd (вообще их намного больше). Мы же поставим еще один PAM-модуль: для проверки через LDAP. А еще мы дополним NSS-переключатель новой опцией, чтобы он говорил всем, что можно проверять не только через passwd, но и через LDAP.
Сложность аутентификации SSH состоит в том, что запроcы будут идти к объектам PosixAccount, а в нормальном LDAP таким делать нечего. Кроме того, желательно также, чтобы в LDAP проверялись не пароли, а публичная часть ключа.
Итак сначала сделаем, чтобы проверялись хотя бы пароли, а уж потом и ключи допилим.
В моем случае используются:
Начнем с того, что сохраним в безопасное место файл nsswitch.conf, который каждая вражеская программа пытается изкорёжить:
Теперь научим наш PAM работать с LDAP-сервером. Для этого нам понадобятся модуль PAM, которому собственно предстоит работать с LDAP, и модуль NSS ( Name Service Switch), который к этому LDAP доступ для PAM'а обеспечит. Ну и консольные LDAP-утилиты для удобство дебага проблем:
В процессе установки будут запрошены некоторые параметры (ваши ответы врядли совпадут с моими, так как у меня специфический LDAP-сервер, я просто привожу пример):
Нужно также учесть, что возможно пользователь впервые подключается к системе (ведь сисадмин не бегал по всем серверам и не создавал учетку с домашней директорией). Поэтому заставим PAM автоматически создавать такую директорию (припишем в самом низу):
Для тех, кто хочет использовать аутентификацию по паролю, а их LDAP использует PosixAccount, на этом мануал будет закончен. Но у нас не все так сладко.
Для пользователей Oracle/SUN DSEE (Directory Server Enterprise Edition) придется каждому существующему пользователю добавить дополнительный класс и несколько его полей.
Как это сделать, написано тут.
Теперь можно пробовать приконнектиться по SSH со своим пользователем. Если не получилось, нужно смотреть логи запросов LDAP - как правило только они и спасают.
Если все ровно, то вот Вам новая проблема. Обратите внимание, что любая команда, подразумвающая обращение к LDAP (да хотябы ls, который показывает владельца файла) отвечает долго. Это из-за того, что она каждый раз обращается к LDAP. Во избежание этого нужно включить кэширование всех NSS-запросов: nscd. Но этому посвящено пол интернета, так что я обойду эту тему.
**********
Делается это следующим образом. Как многие знают, сегодня считается моветоном делать самостоятельные проверки паролей, групп и прочего. Давным давно уже изобрели единый центр проверок PAM. Даже утилита login, которая запускается, когда Вы коннектитесь к консоли, проверяет не сама, а отдает эту задачу "на аутсурс" PAM'у. Соответственно и OpenSSH сам не проверяет пароли.
Изначально у нас есть PAM-модуль для проверки через passwd (вообще их намного больше). Мы же поставим еще один PAM-модуль: для проверки через LDAP. А еще мы дополним NSS-переключатель новой опцией, чтобы он говорил всем, что можно проверять не только через passwd, но и через LDAP.
Сложность аутентификации SSH состоит в том, что запроcы будут идти к объектам PosixAccount, а в нормальном LDAP таким делать нечего. Кроме того, желательно также, чтобы в LDAP проверялись не пароли, а публичная часть ключа.
Итак сначала сделаем, чтобы проверялись хотя бы пароли, а уж потом и ключи допилим.
В моем случае используются:
OS: Debian Squeeze
LDAP: Oracle DSEE7
Начнем с того, что сохраним в безопасное место файл nsswitch.conf, который каждая вражеская программа пытается изкорёжить:
cp /etc/nsswitch.conf /etc/nsswitch.conf.origchattr +i /etc/nsswitch.conf.orig
Теперь научим наш PAM работать с LDAP-сервером. Для этого нам понадобятся модуль PAM, которому собственно предстоит работать с LDAP, и модуль NSS ( Name Service Switch), который к этому LDAP доступ для PAM'а обеспечит. Ну и консольные LDAP-утилиты для удобство дебага проблем:
Прошу обратить внимание на букву "d" в конце слов libnss-ldapd и libpam-ldapd. Раньше эти модули назывались без нее: libnss-ldap и libpam-ldap. Но потом их улучшили и переименовали. Если ошибетесь и поставите старые, то будете сами конфигурировать nscd и nslcd. И вообще там больше геморроя. А новые модули сами все делают.apt-get install ldapscripts libnss-ldapd libpam-ldapd
В процессе установки будут запрошены некоторые параметры (ваши ответы врядли совпадут с моими, так как у меня специфический LDAP-сервер, я просто привожу пример):
LDAP server Uniform Resource Identifier:ldaps://ldap.nodesquad.com:1686/Distinguished name of the search base:dc=nodesquad,dc=com* (напротив всех сервисов поставить галочки )
Нужно также учесть, что возможно пользователь впервые подключается к системе (ведь сисадмин не бегал по всем серверам и не создавал учетку с домашней директорией). Поэтому заставим PAM автоматически создавать такую директорию (припишем в самом низу):
vi /etc/pam.d/common-session
#Automatically create home direcory if not exist
session required pam_mkhomedir.so skel=/etc/skel/ umask=0077
Для тех, кто хочет использовать аутентификацию по паролю, а их LDAP использует PosixAccount, на этом мануал будет закончен. Но у нас не все так сладко.
Для пользователей Oracle/SUN DSEE (Directory Server Enterprise Edition) придется каждому существующему пользователю добавить дополнительный класс и несколько его полей.
Как это сделать, написано тут.
Теперь можно пробовать приконнектиться по SSH со своим пользователем. Если не получилось, нужно смотреть логи запросов LDAP - как правило только они и спасают.
Если все ровно, то вот Вам новая проблема. Обратите внимание, что любая команда, подразумвающая обращение к LDAP (да хотябы ls, который показывает владельца файла) отвечает долго. Это из-за того, что она каждый раз обращается к LDAP. Во избежание этого нужно включить кэширование всех NSS-запросов: nscd. Но этому посвящено пол интернета, так что я обойду эту тему.
**********
А тебя, Миш, не смущает, что пароль в LDAP передается открытым текстом по сети?
ОтветитьУдалитьСправедливое замечание. Тогда там выше вместо
Удалитьldap://ldap.nodesquad.com:1389/
надо писать:
ldaps://ldap.nodesquad.com:1686/