§ SSH, PublicKeys and Sudo under OpenLDAP

Настройка авторизации в LDAP для SSH и Sudo.

Статья описывает процесс настройки системы в которой:

• аккаунты и группы хранятся в LDAP;
• публичные SSH ключи хранятся в LDAP;
• SSH выполняет аутентификацию и авторизацию в LDAP;
• информация о sudoers хранится в LDAP;
• sudo выполняет авторизацию в LDAP;

Настройка выполняется в Gentoo Linux, хотя тоже самое можно проделать в любом другом дистрибутиве при наличии соответствующих пакетов.
Настройка сервера.
Серверная часть представляет собой сервер OpenLDAP. Сначала устанавливаем соответствующие пакеты. Установка выполняется с помощью paludis.
# vi /etc/paludis/use.conf
app-admin/sudo ldap
net-misc/openssh ldap
net-nds/openldap odbc
# cave resolve net-nds/openldap app-admin/sudo net-misc/openssh -x

После установки следует сгенерировать пароль который будет использоваться для учетной записи администратора LDAP.
# slappasswd
New password: 
Re-enter new password:
{SSHA}9/f5C/34XA2UggRPA8I93MjAt8ju1d/F

Также необходимо создать самоподписанный сертификат и ключ (срок действия - 10 лет) для SSL и TLS подключений.
# openssl req -config /etc/ssl/openssl.cnf -new -x509 -nodes \
-out /etc/ssl/ldap.pem -keyout /etc/openldap/ssl/ldap.pem -days 3650

Переходим к настройке slapd - сервера OpenLDAP. Настройка сводится к подключению дополнительных схем, определению настроек для TLS и самое главное, выполняется настройка каталога. Также указываем сгенерированный пароль (rootpw) для административной учетной записи (rootdn)
# vi /etc/openldap/slapd.conf
include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/nis.schema
include         /etc/openldap/schema/misc.schema
include         /etc/openldap/schema/openldap.schema
include         /etc/openldap/schema/openssh-lpk.schema
include         /etc/openldap/schema/sudo.schema

# TLS related settings 
TLSCertificateFile /etc/ssl/ldap.pem
TLSCertificateKeyFile /etc/openldap/ssl/ldap.pem
TLSCACertificateFile /etc/ssl/ldap.pem

pidfile         /var/run/openldap/slapd.pid
argsfile        /var/run/openldap/slapd.args

# allow users change their passwords
access to attrs=userPassword
        by self write
        by anonymous auth
        by users none
access to * by * read

# Directory settings
database        hdb
suffix          "dc=thislinux,dc=org"
checkpoint      32      30 
rootdn          "cn=Manager,dc=thislinux,dc=org"
rootpw          {SSHA}9/f5C/34XA2UggRPA8I93MjAt8ju1d/F
directory       /var/lib/openldap-data/thislinux.org
index   objectClass     eq

Теперь создаем каталог для нашего каталога. Копируем недостающую схему, проверяем конфигурацию и запускаем slapd.
# mkdir /var/lib/openldap-data/thislinux.org
# chown ldap:  /var/lib/openldap-data/thislinux.org
# chmod 700 /var/lib/openldap-data/thislinux.org
# cp /var/lib/openldap-data/DB_CONFIG.example /var/lib/openldap-data/thislinux.org/DB_CONFIG
# cp /usr/share/doc/sudo-1.8.6_p3/schema.OpenLDAP /etc/openldap/schema/sudo.schema
# slaptest -u -f /etc/openldap/slapd.conf
config file testing succeeded
# /etc/init.d/slapd start

Теперь выполняем настройку локального клиентского подключения к LDAP
# vi /etc/openldap/ldap.conf
BASE    dc=thislinux,dc=org
URI     ldap://ldap.thislinux.org
TIMELIMIT       15

Сейчас, пожалуй самый сложный этап в настройке - создание схемы каталога. Несколько слов о будущей структуре каталога. Корневым узлом будет наша организация, внутри нее будет две абстрактных сущности в виде организационных единиц (ou): люди (ou=people) и проекты (ou=projects). Внутри people, создадим более четкую структуру: учетные записи (ou=accounts) - здесь будут перечислены учетные записи сотрудников; роли (ou=roles) - здесь мы определим основные роли в организации, на основании ролей мы будем привязываться к sudoers; группы sudo (ou=sudoers) - здесь мы определим конкретные правила для sudo. Вторая сущность - ou=projects - является вместилищем проектов. С этими проектами будут ассоциироваться учетные записи. И на основе принадлежности к проектам будет осуществляться доступ на сервера.
init.ldif - начальная схема каталога
# ldapadd -x -W -D "cn=Manager,dc=thislinux,dc=org" -f init.ldif 
Enter LDAP Password: 
adding new entry "dc=thislinux,dc=org"
adding new entry "ou=people,dc=thislinux,dc=org"
adding new entry "ou=accounts,ou=people,dc=thislinux,dc=org"
adding new entry "ou=roles,ou=people,dc=thislinux,dc=org"
adding new entry "ou=sudoers,ou=people,dc=thislinux,dc=org"
adding new entry "ou=projects,dc=thislinux,dc=org"

Дальше создаем роли в виде POSIX групп, с этими группами будут ассоциироваться учетные записи для дальнейшего определения прав sudo.
posix-groups.ldif - схема групп

dn: cn=testers,ou=roles,ou=people,dc=thislinux,dc=org cn: testers objectClass: posixGroup gidNumber: 1010 dn: cn=support,ou=roles,ou=people,dc=thislinux,dc=org cn: support objectClass: posixGroup gidNumber: 1011 dn: cn=developers,ou=roles,ou=people,dc=thislinux,dc=org cn: developers objectClass: posixGroup gidNumber: 1012 dn: cn=admins,ou=roles,ou=people,dc=thislinux,dc=org cn: admins objectClass: posixGroup gidNumber: 1013

# ldapadd -x -W -D "cn=Manager,dc=thislinux,dc=org" -f posix-groups.ldif 
Enter LDAP Password: 
adding new entry "cn=testers,ou=roles,ou=people,dc=thislinux,dc=org"
adding new entry "cn=support,ou=roles,ou=people,dc=thislinux,dc=org"
adding new entry "cn=developers,ou=roles,ou=people,dc=thislinux,dc=org"
adding new entry "cn=admins,ou=roles,ou=people,dc=thislinux,dc=org"

Создаем учетные записи пользователей, в записи определяем gid группы которой будет принадлежать учетная запись. Таким образом мы определяем привилегии sudo для учетной записи. Пока хватит одной учетной записи.

posix-account.ldif - образец учетной записи

dn: uid=lesovsky,ou=accounts,ou=people,dc=thislinux,dc=org cn: Alexey Lesovsky givenName: Alexey sn: Lesovsky uid: lesovsky uidNumber: 10000 gidNumber: 1011 homeDirectory: /home/alesovsky mail: lesovsky@gmail.com loginShell: /bin/bash objectClass: inetOrgPerson objectClass: ldapPublicKey objectClass: organizationalPerson objectClass: person objectClass: posixAccount objectClass: shadowAccount sshPublicKey: ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAgEAuvx8QK4zjtGOXLPsBUAdcIQX6oFG ####################### publicKey ########################################### AQtI9LaEj4kbIG8kq6bh7Ygg2aR4xaA6/YA/wMM= lesovsky

# ldapadd -x -W -D "cn=Manager,dc=thislinux,dc=org" -f posix-account.ldif 
Enter LDAP Password: 
adding new entry "uid=lesovsky,ou=accounts,ou=people,dc=thislinux,dc=org"

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

project.ldif - образцы проектов

dn: cn=thinsearch,ou=projects,dc=thislinux,dc=org cn: thinsearch gidNumber: 10000 memberUid: lesovsky objectClass: posixGroup dn: cn=widescope,ou=projects,dc=thislinux,dc=org cn: widescope gidNumber: 10001 objectClass: posixGroup

# ldapadd -x -W -D "cn=Manager,dc=thislinux,dc=org" -f project.ldif 
Enter LDAP Password: 
adding new entry "cn=thinsearch,ou=projects,dc=thislinux,dc=org"
adding new entry "cn=widescope,ou=projects,dc=thislinux,dc=org"

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

sudoers.ldif - sudoers структуры

dn: cn=defaults,ou=sudoers,ou=people,dc=thislinux,dc=org objectClass: top objectClass: sudoRole cn: defaults description: Default sudoOption's go here sudoOrder: 1 sudoOption: always_set_home sudoOption: env_keep+="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS" sudoOption: env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES" sudoOption: env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE" sudoOption: env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY" sudoOption: env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE" sudoOption: env_reset sudoOption: secure_path=/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin dn: cn=root,ou=sudoers,ou=people,dc=thislinux,dc=org objectClass: top objectClass: sudoRole cn: root sudoUser: root sudoHost: ALL sudoRunAsUser: ALL sudoCommand: ALL sudoOrder: 2 dn: cn=%testers,ou=sudoers,ou=people,dc=thislinux,dc=org objectClass: top objectClass: sudoRole cn: %testers sudoUser: %testers sudoHost: ALL sudoRunAsUser: root sudoCommand: (service sudoCommand: nobody) ALL sudoCommand: /bin/true sudoOption: !authenticate sudoOrder: 3 dn: cn=%support,ou=sudoers,ou=people,dc=thislinux,dc=org objectClass: top objectClass: sudoRole cn: %support sudoUser: %support sudoHost: ALL sudoRunAsUser: root sudoCommand: (service sudoCommand: nobody) ALL sudoCommand: /usr/bin/traceroute sudoCommand: /usr/bin/iotop sudoCommand: /usr/sbin/tcpdump sudoCommand: /bin/nice sudoCommand: /bin/kill sudoCommand: /usr/bin/killall sudoOption: !authenticate sudoOrder: 4 dn: cn=%developers,ou=sudoers,ou=people,dc=thislinux,dc=org objectClass: top objectClass: sudoRole cn: %developers sudoUser: %developers sudoHost: ALL sudoRunAsUser: root sudoCommand: (service sudoCommand: nobody) ALL sudoCommand: /usr/bin/traceroute sudoCommand: /usr/bin/iotop sudoCommand: /usr/sbin/tcpdump sudoCommand: /bin/nice sudoCommand: /bin/kill sudoCommand: /usr/bin/killall sudoCommand: /usr/bin/cave sudoOption: !authenticate sudoOrder: 5 dn: cn=%admins,ou=sudoers,ou=people,dc=thislinux,dc=org objectClass: top objectClass: sudoRole cn: %admins sudoUser: %admins sudoHost: ALL sudoRunAsUser: ALL sudoCommand: ALL sudoCommand: !SU sudoOrder: 6

# ldapadd -x -W -D "cn=Manager,dc=thislinux,dc=org" -f sudoers.ldif 
Enter LDAP Password: 
adding new entry "cn=defaults,ou=sudoers,ou=people,dc=thislinux,dc=org"
adding new entry "cn=root,ou=sudoers,ou=people,dc=thislinux,dc=org"
adding new entry "cn=%testers,ou=sudoers,ou=people,dc=thislinux,dc=org"
adding new entry "cn=%support,ou=sudoers,ou=people,dc=thislinux,dc=org"
adding new entry "cn=%developers,ou=sudoers,ou=people,dc=thislinux,dc=org"
adding new entry "cn=%admins,ou=sudoers,ou=people,dc=thislinux,dc=org"

Настройка сервера может считаться завершенной.

Переходим к клиенту. 
Для настройки клиента, также нужно установить несколько пакетов. Здесь стоит отметить что один из пакетов, app-admin/authconfig не идет в официальном дереве portage, поэтому берем его из zugaina.
# vi /etc/paludis/use.conf
net-nds/openldap minimal
sys-libs/tdb python
sys-libs/talloc python
app-crypt/mit-krb5 openldap
net-misc/openssh ldap
app-admin/sudo ldap
# cave resolve app-admin/authconfig sys-auth/pam_ldap sys-auth/sssd net-misc/openssh app-admin/sudo -x

Копируем ранее сгенерированный сертификат на клиентскую машину
# scp ldap.thislinux.org:/etc/ssl/ldap.pem /etc/openldap/cacerts/

Переходим к настройке и запуску sssd.
# vi /etc/sss/sssd.conf
[sssd]
config_file_version = 2
services = nss, pam
domains = default

[nss]
filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd

[pam]

[domain/default]
ldap_tls_reqcert = allow
id_provider = ldap
auth_provider = ldap
ldap_schema = rfc2307bis
ldap_uri = ldaps://ldap.thislinux.org
ldap_search_base = dc=thislinux,dc=org
ldap_group_member = uniquemember
ldap_id_use_start_tls = true
chpass_provider = ldap
ldap_chpass_uri = ldaps://ldap.thislinux.org
enumerate = false
cache_credentials = true
entry_cache_timeout = 600
ldap_network_timeout = 3
ldap_access_filter = (&(objectclass=shadowaccount)(objectclass=posixaccount))

Выставляем "суровые" права на файл конфигурации 
# chmod 600 /etc/sssd/sssd.conf

И осталось определить порядок просмотра и источники поиска для NSS (Диспечтер служб имен). Находим три строки и приводим их в соответствующий вид:
# vi /etc/nswitch.conf
passwd:     files sss
shadow:     files sss
group:      files sss

Запускаем authconfig, выпавшие ошибки игнорируем, т.к. скрипт написан под специфику RedHat Linux. После чего запускаем сервис sssd.
# authconfig --enablesssd --enablesssdauth --enablecachecreds --enableldap \
--disableldaptls --enableldapauth --ldapserver=ldap.thislinux.org \
--ldapbasedn="ou=accounts,ou=people,dc=thislinux,dc=org" --disablenis \
--disablekrb5  --enableshadow --enablemkhomedir --enablelocauthorize --passalgo=sha512 \
--updateall
# /etc/init.d/sssd start

Теперь правим общие настройки для клиентского подключения к LDAP (обращаем внимание на использование TLS)
# vi /etc/openldap/ldap.conf
BASE ou=accounts,ou=people,dc=thislinux,dc=org
URI ldaps://ldap.thislinux.org/
TIMELIMIT       15
TLS_REQCERT allow
TLS_CACERTDIR /etc/openldap/cacerts

Проверяем работоспособность подключения к LDAP, если проверка завершилось ошибкой "No such user" следует остановиться и все перепроверить, т.к. дальше идти смысла нет. 
# id lesovsky
uid=10000(lesovsky) gid=1011(support) groups=1011(support)

В случае успешной проверки настраиваем sshd на работу с LDAP. Способность sshd брать ключи из LDAP каталога, реализована с помощью патчей проекта LPK. При настройке следует учесть один момент, LPK не умеет обращаться напрямую к идентификаторам ldaps:// поэтому он работает только со стандартными ldap:// ссылками, но с инициализацией TLS соединения. Настройка сводится к указанию параметров LPK внутри конфигурации sshd и к определению настроек для подключения к LDAP. Следует обратить внимание на параметр LpkServerGroup - здесь мы указываем тот самый проект. Учетные записи принадлежащие проекту смогут попасть на сервер. Остальным - вход запрещен. 
# /etc/ssh/sshd_config 
LogLevel VERBOSE
PasswordAuthentication no
UsePAM yes
PrintMotd no
PrintLastLog no
UseLPK yes
LpkLdapConf /etc/ldap.conf
LpkServers  ldap://ldap.thislinux.org
LpkUserDN   ou=accounts,ou=people,dc=thislinux,dc=org
LpkGroupDN  ou=projects,dc=thislinux,dc=org
LpkBindDN cn=Manager,dc=thislinux,dc=org
LpkBindPw klfgflvby
LpkServerGroup widescope
LpkForceTLS yes
LpkSearchTimelimit 3
LpkBindTimelimit 3
LpkPubKeyAttr sshPublicKey
Subsystem       sftp    /usr/lib64/misc/sftp-server

# vi /etc/ldap.conf 
uri ldap://ldap.thislinux.org/
port 636
binddn cn=Manager,dc=thislinux,dc=org
bindpw Здесь_Указываем_Пароль
base ou=accounts,ou=people,dc=thislinux,dc=org
timelimit 30
bind_timelimit 30
ssl start_tls
tls_cacertdir /etc/openldap/cacerts
pam_password md5
# /etc/init.d/sshd restart

Завершающий этап - настройка sudo. Sudo умеет самостоятельно подключаться к LDAP и для этого ему требуется отдельный файл конфигурации.
# vi /etc/ldap.conf.sudo
uri ldap://ldap.thislinux.org
ssl start_tls
sudoers_base ou=sudoers,ou=people,dc=thislinux,dc=org
bind_timelimit 3
timelimit 3
sudoers_debug 0

Для диспетчера NSS указываем источник где брать информацию о sudoers.
# vi /etc/nsswitch.conf
sudoers: ldap files 

На этом настройка считается завершенной и можно приступить к тестированию.
Для начала задаем пароль для нашей, пока единственной учетной записи:
# ldappasswd -x -W -D "cn=Manager,dc=thislinux,dc=org" \
-s qwerty "uid=lesovsky,ou=accounts,ou=people,dc=thislinux,dc=org"

Сначала проверим используется ли TLS в ходе подключения к LDAP. Это можно проверить через ldapsearch с параметрами -Z[Z] (часть вывода опущено).
# ldapsearch -x -b -H ldaps://ldap.thislinux.org -D "cn=Manager,dc=thislinux,dc=org" -W -d 1 -ZZ
.....
TLS trace: SSL_connect:before/connect initialization
TLS trace: SSL_connect:SSLv2/v3 write client hello A
TLS trace: SSL_connect:SSLv3 read server hello A
TLS certificate verification: depth: 0, err: 0, subject: /C=RU/ST=Sverdlovskaya obl./L=Yekaterinburg/O=Thislinux/OU=development/CN=ldap.thislinux.org/emailAddress=lesovsky@gmail.com, issuer: /C=RU/ST=Sverdlovskaya obl./L=Yekaterinburg/O=Thislinux/OU=development/CN=ldap.thislinux.org/emailAddress=lesovsky@gmail.com
TLS trace: SSL_connect:SSLv3 read server certificate A
TLS trace: SSL_connect:SSLv3 read server done A
TLS trace: SSL_connect:SSLv3 write client key exchange A
TLS trace: SSL_connect:SSLv3 write change cipher spec A
TLS trace: SSL_connect:SSLv3 write finished A
TLS trace: SSL_connect:SSLv3 flush data
TLS trace: SSL_connect:SSLv3 read server session ticket A
TLS trace: SSL_connect:SSLv3 read finished A
....

Теперь можно приступить к тестированию. Для порядка можно следовать такому плану:

• попытка подключения неавторизованного пользователя - учетная запись не принадлежит ни одной из групп, без ключа, известен только пароль -  в результате нельзя попасть на сервер;
• подключения участника thinsearch - учетная запись находится в проекте thinsearch - в результате сервер разрешает входить участникам группы thinsearch;
• подключения участника widescope - учетная запись находится в проекте widescope - в результате сервер НЕ разрешает входить участникам группы widescope;
• проверки sudo. учетной записи присвоен gid %testers - в результате учетная запись способна выполнять команды разрешенные для %testers через sudo.
• проверки sudo. учетной записи присвоен gid %testers - попытка выполнить команду не определенную в sudo, должна завершится неудачей;
• проверки sudo. учетной записи присвоен gid %developers - попытки выполнить команды перечисленные в %developers должны завершаться успешно;
• проверка смены пароля - попытка сменить пароль через passwd, для пользователя подключившегося к серверу, должна завершаться успешно.

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

На главную "Virtualizing Linux"