Таким образом, пользователь пытается получить доступ к блоку, который отскочил бы на сервер LDAP с информацией о сервере и пользователе. Затем он проверит, имеет ли этот человек доступ к этому серверу.
И да и нет. Назначение сервера LDAP - хранить информацию, а не выполнять произвольные проверки. (Это просто база данных.)
Таким образом, вы можете достичь этого, но фактические проверки авторизации будут выполняться sshd-стороной (служба сама решает, принимать пользователей или нет). В Linux это обычно происходит внутри модуля PAM, принадлежащего клиентскому программному обеспечению LDAP (nslcd или sssd).
и потенциально вернуть коррелирующий ключ для предоставления доступа.
Обратите внимание на разницу между аутентификацией и авторизацией. Первый проверяет, кто пользователь; последний проверяет, что пользователю разрешено делать.
Поэтому, хотя можно настроить программное обеспечение LDAP таким образом, чтобы оно не возвращало никаких ключей (поскольку оно уже знает, что пользователю будет отказано позже), это не то, как работают клиенты LDAP по умолчанию, и это может быть более трудным для реализации ,
Вместо этого это нормально, что сервер LDAP всегда возвращает SSH-ключи, которые sshd будет принимать их на этапе аутентификации - потому что если пользователю не разрешено использовать сервер, они все равно будут отклонены на этапе авторизации.
Последний метод имеет то преимущество, что он одинаково хорошо работает независимо от механизма аутентификации. Независимо от того, проходит ли пользователь аутентификацию с использованием пароля, ключа SSH, или смарт-карты, или токена Kerberos, они все равно будут отклонены (или приняты).
После некоторого исследования кажется возможным сделать вышеупомянутое, но я не мог найти где-нибудь это для определенных серверов.
Как упоминалось выше, может быть проще отделить поиск ключа от авторизации.
Сконфигурируйте клиентское программное обеспечение LDAP (SSSD или nslcd) для получения информации о пользователе из каталога и проверки авторизации с использованием некоторых правил. (Самый традиционный метод - использовать host: attribute в учетных записях пользователей.)
Проверьте, правильно ли проверяет привилегии SSSD pam_sss (или pam_ldap nslcd), используя pamtester sshd Someusername acct_mgmt .
Сконфигурируйте AuthorizedKeysCommand в sshd_config для получения ключей из LDAP. Если вы выбрали SSSD ранее, у него есть встроенная вспомогательная программа для этого; в противном случае вам, возможно, придется написать свой собственный.
столкнуться с несколькими проблемами, такими как контрольная сумма в файлах конфигурации и т. д.
OpenLDAP имеет два формата конфигурации:
- Простой текстовый файл
slapd.conf , который редактируется напрямую и не имеет контрольных сумм.
- Основанный на LDAP
cn=config , который, несмотря на то, что он хранится на диске в виде текстовых файлов LDIF, не предназначен для непосредственного редактирования. После того, как вы создадите конфигурацию cn = config, вы должны будете выполнять все редактирование через сам LDAP (или через slapadd если необходимо).
Вы нашли контрольные суммы, когда смотрели на второй вариант. Я могу только предположить, что они там как сдерживающий фактор против прямого редактирования (это не невозможно, но не должно быть сделано кроме чрезвычайных ситуаций).
