Поэтому я ищу решение для доступа по ssh-ключам для доступа к многочисленным серверам, и было обращено внимание на использование LDAP. Я хотел представить пример использования и посмотреть, будет ли применим LDAP, и будут ли использованы любые предложения или помощь.

Можно ли использовать LDAP для ограничения доступа к конкретным серверам для каждого пользователя / группы с использованием ключей ssh. Таким образом, пользователь пытается получить доступ к блоку, который отскочил бы на сервер LDAP с информацией о сервере и пользователе. Затем он проверит, имеет ли этот человек доступ к этому серверу, и, возможно, вернет соответствующий ключ для предоставления доступа.

После некоторого исследования кажется возможным сделать вышеупомянутое, но я не мог найти где-нибудь это для определенных серверов.

Также лучше использовать openLDAP, я попытался настроить это и столкнулся с несколькими проблемами, такими как контрольная сумма в файлах конфигурации и т.д.

2 ответа2

0

Таким образом, пользователь пытается получить доступ к блоку, который отскочил бы на сервер LDAP с информацией о сервере и пользователе. Затем он проверит, имеет ли этот человек доступ к этому серверу.

И да и нет. Назначение сервера LDAP - хранить информацию, а не выполнять произвольные проверки. (Это просто база данных.)

Таким образом, вы можете достичь этого, но фактические проверки авторизации будут выполняться sshd-стороной (служба сама решает, принимать пользователей или нет). В Linux это обычно происходит внутри модуля PAM, принадлежащего клиентскому программному обеспечению LDAP (nslcd или sssd).

и потенциально вернуть коррелирующий ключ для предоставления доступа.

Обратите внимание на разницу между аутентификацией и авторизацией. Первый проверяет, кто пользователь; последний проверяет, что пользователю разрешено делать.

Поэтому, хотя можно настроить программное обеспечение LDAP таким образом, чтобы оно не возвращало никаких ключей (поскольку оно уже знает, что пользователю будет отказано позже), это не то, как работают клиенты LDAP по умолчанию, и это может быть более трудным для реализации ,

Вместо этого это нормально, что сервер LDAP всегда возвращает SSH-ключи, которые sshd будет принимать их на этапе аутентификации - потому что если пользователю не разрешено использовать сервер, они все равно будут отклонены на этапе авторизации.

Последний метод имеет то преимущество, что он одинаково хорошо работает независимо от механизма аутентификации. Независимо от того, проходит ли пользователь аутентификацию с использованием пароля, ключа SSH, или смарт-карты, или токена Kerberos, они все равно будут отклонены (или приняты).

После некоторого исследования кажется возможным сделать вышеупомянутое, но я не мог найти где-нибудь это для определенных серверов.

Как упоминалось выше, может быть проще отделить поиск ключа от авторизации.

  1. Сконфигурируйте клиентское программное обеспечение LDAP (SSSD или nslcd) для получения информации о пользователе из каталога и проверки авторизации с использованием некоторых правил. (Самый традиционный метод - использовать host: attribute в учетных записях пользователей.)

    Проверьте, правильно ли проверяет привилегии SSSD pam_sss (или pam_ldap nslcd), используя pamtester sshd Someusername acct_mgmt .

  2. Сконфигурируйте AuthorizedKeysCommand в sshd_config для получения ключей из LDAP. Если вы выбрали SSSD ранее, у него есть встроенная вспомогательная программа для этого; в противном случае вам, возможно, придется написать свой собственный.

столкнуться с несколькими проблемами, такими как контрольная сумма в файлах конфигурации и т. д.

OpenLDAP имеет два формата конфигурации:

  • Простой текстовый файл slapd.conf , который редактируется напрямую и не имеет контрольных сумм.
  • Основанный на LDAP cn=config , который, несмотря на то, что он хранится на диске в виде текстовых файлов LDIF, не предназначен для непосредственного редактирования. После того, как вы создадите конфигурацию cn = config, вы должны будете выполнять все редактирование через сам LDAP (или через slapadd если необходимо).

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

0

LDAP управляет многими аспектами сети, а также может быть настроен для хранения открытых ключей SSH. Для этого необходимо, чтобы клиент SSH был настроен на запрос LDAP для получения необходимой информации.

Инструкции по настройке вы найдете в статье «Ошибка сервера» аутентификации SSH-ключа с использованием LDAP, как:

  • Обновите LDAP, чтобы включить схему OpenSSH-LPK
  • Создайте скрипт, который запрашивает LDAP для открытого ключа пользователя.
  • Обновите sshd_config чтобы он указывал на скрипт из предыдущего шага

LDAP в этом случае функционирует только как база данных с контролем доступа. Подобные результаты могут быть достигнуты без LDAP с различными другими типами продуктов, начиная от корпоративных брандмауэров и заканчивая сложным администрированием, предлагающим решения с единым входом.

Если вы хотите использовать другие продукты, кроме LDAP, список очень длинный. Я бы посоветовал воспользоваться услугами компании или консультанта, который работает в области сетевой безопасности. Правильное решение для вас зависит от многих факторов, таких как ваше географическое положение, доступное оборудование и не забывая бюджет.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .