Решено: Централизованное управление доступом по ssh (ldap - простое красивое решение)

[Deo]

Прошу сильно не пинать, т.к. мой опыт в администрировании акцентирован на LAMP-стеке.

Возникла задача малой кровью покончить с анархией с доступом ко внешним ресурсам.
Если в двух словах - необходимо централизованно управлять правами доступа по ssh к различным серверам. Клиенты находятся в локальной сети. Сеть имеет внешний статический IP.

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

SSO не критичен. Kerberos поднимать очень не хочется.
Всему этому описанию теоретически соответствует связка LDAP+PAM+SSH, но гугл ничего путного не подсказал. Возожно, я просто не знаю нужных ключевых слов.

[Ленивая Бестолочь]

Всему этому описанию теоретически соответствует связка LDAP+PAM+SSH, но гугл ничего путного не подсказал.

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

[Deo]

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

Спасибо. Лучше пойти вторым путем.

Что я успешно сделал на данный момент:
- поднял виртуальный контейнер;
- поднял sshd, openLDAP2, apache, phpldapamin;
- пробросил 22, 80 и 389 порты на хост;
- проверил работоспособность всего вышеперечисленного и доступность из локальной сети.

Куда двигаться дальше?

[Ленивая Бестолочь]

тогда я назадаю кучу вопросов :-)

это всё делается на openSUSE?

в лдап у вас базовая структура создана? это в phpldapadmin можно глянуть, либо командой ldapsearch.
должна быть картина типа
dc=domain,dc=com
|
\__ou=users
\__ou=groups
|
......
или на подобии. проверьте там наличие ветки ou=netgroup....

настроена ли авторизицая ОС через лдап?
покажите /etc/nsswitch.conf, а так же /etc/pam.d/* или /etc/pamd.conf

вы можете завести в лдапе одного юзера и одну группу для теста?
в выводе getent passwd и getent group на хосте будет их видно?

[Deo]

Вопросы - это всегда хорошо.

это всё делается на openSUSE?

Клиенты - разномастный зоопарк.
Сервер - да. Была проблема с созданием posix группы. Решил темплейтом для phpldapadmin отсюда http://sourceforge.net/tracker/?func=detai...;group_id=61828

вы можете завести в лдапе одного юзера и одну группу для теста?
в выводе getent passwd и getent group на хосте будет их видно?

Да, я времени не терял. :) Уже есть одна группа и два пользователя.
Группа и пользователи видны в getent.
На хосте клиент настроен. id и su для пользователей из ldap работает. В процессе успел заметить, что коллизия uid локального и ldap пользователей - не есть хорошо.


Структура на данный момент такая:
dc=virtual
|
\__ou=groups
\__ou=people
|

ветку ou=netgroup не создавал, т.к. не знаю, что там должно быть. В матчасти слабоват, но быстро учусь. Сейчас пытаюсь вкурить, как сюда подвязать ресурсы.

Конфиги

Код: Выделить всё

#
# /etc/nsswitch.conf
#
# passwd: files nis
# shadow: files nis
# group:  files nis

passwd: compat
group:  files ldap

hosts:  files mdns4_minimal [NOTFOUND=return] dns wins
networks:       files dns

services:       files ldap
protocols:      files
rpc:    files
ethers: files
netmasks:       files
netgroup:       files ldap
publickey:      files

bootparams:     files
automount:      files nis
aliases:        files ldap
passwd_compat:  ldap

в /etc/pam.d/ много лишнего.
Вот /etc/pam.d/common-account

#%PAM-1.0
#
# This file is autogenerated by pam-config. All changes
# will be overwritten.
#
# Account-related modules common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the accountorization modules that define
# the central access policy for use on the system. The default is to
# only deny service to users whose accounts are expired.
#
account requisite pam_unix2.so
account sufficient pam_localuser.so
account required pam_ldap.so use_first_pass

[Ленивая Бестолочь]

Группа и пользователи видны в getent.
На хосте клиент настроен. id и su для пользователей из ldap работает. В процессе успел заметить, что коллизия uid локального и ldap пользователей - не есть хорошо.

разбирайтесь с коллизиями и пробуйте зайти по ssh на компьютер клиент-лдапа. убедитесь, что пускают пользователей из лдап.

если пускают, то переходим к контролю доступа собственно:

я много читал о проблемах с negroup: files, грубо говоря - оно нифига не работает, так что можно смело переделать:

netgroup: files ldap

на

netgroup: ldap

далее. создавайте ветку netgroups, для этого можно, например файлик

Код: Выделить всё

dn: ou=Netgroups,dc=raccoonia,dc=org
objectClass: top
objectClass: organizationalUnit
ou: Netgroups

загрузить командой

Код: Выделить всё

ldapadd  -c -W -D cn=admin,dc=raccoonia,dc=org -xH ldap://localhost -f netgroup.ldif

имя домена, конечно же везде меняйте на ваше.
можете сделать с помощью phpldapadmin, как вам угодно.

далее в файле /etc/libnss-ldap.conf (debian-based) или /etc/ldap.conf или /etc/ldap/ldap.conf (другие дистрибутивы) добавляйте строку:

Код: Выделить всё

nss_base_netgroup    ou=Netgroups,dc=raccoonia,dc=org?one

имя домена, конечно ваше.
можно писать просто

Код: Выделить всё

nss_base_netgroup    ou=Netgroups

, но, пишут, что снижается производительность. никрута.
четкого стандарта для имени контейнера я не знаю. возможно оно и не Netgroups.

далее добавляем простую нетгруппу. для примера будем пускать на все хосты домена raccoonia.org только юзера user1:

Код: Выделить всё

dn: cn=sysadmin,ou=Netgroups,dc=raccoonia,dc=org
objectClass: nisNetgroup
objectClass: top
cn: sysadmin
nisNetgroupTriple: (,user1,raccoonia.org)

sysadmin - имя нетгруппы.
(!!) nisNetgroupTriple может быть много. то есть одна нетгруппа определяет кучу разных доступов. один юзер - это только пример.

если всё отлично - включаем доступ к ssh только по нетгруппам. в файл
/etc/hosts.deny добавляем:

Код: Выделить всё

sshd: ALL

а в /etc/hosts.allow:

Код: Выделить всё

sshd: @sysadmin

после этого (на дебиане ничего перезапускать не требуется) при попытке зайти не юзером user1 получаем

Код: Выделить всё

rakul@lucky-star ~/work $ ssh 192.168.0.101 -l user2
ssh_exchange_identification: Connection closed by remote host

в логах сервера:

Код: Выделить всё

Aug 10 19:14:22 debian-2 sshd[1409]: refused connect from 192.168.0.1 (192.168.0.1)

а юзером user1 - всё окей:

Код: Выделить всё

rakul@lucky-star ~/work $ ssh 192.168.0.101 -l user1
user1@192.168.0.101's password:
Linux debian-2 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Aug 10 19:09:00 2012 from 192.168.0.1
Could not chdir to home directory /home/user1: No such file or directory
user1@debian-2:/$

далее рекомендую почитать теорию по нетгруппам и оценить, что можно разграничивать доступ по юзерам, по хостам, юзеров по хостам и т.д. и т.п.
а ещё их можно включать друг в друга.

[Deo]

Большое спасибо, только где-то я налажал.
вот пример, что получилось:

Код: Выделить всё

# /etc/hosts.deny
sshd: ALL

Код: Выделить всё

# /etc/hosts.allow
#intentionally left empty

Код: Выделить всё

deo@victor:~/Documents> ssh user@192.168.0.143
ssh_exchange_identification: Connection closed by remote host
deo@victor:~/Documents> ssh user2@192.168.0.143
ssh_exchange_identification: Connection closed by remote host
deo@victor:~/Documents> ssh localuser@192.168.0.143
ssh_exchange_identification: Connection closed by remote host

ожидаемо. А дальше чудеса.

Код: Выделить всё

# /etc/hosts.allow
sshd: @test

Код: Выделить всё

deo@victor:~/Documents> ssh user@192.168.0.143
Password:
have a lot of fun
deo@victor:~/Documents>exit
deo@victor:~/Documents> ssh user2@192.168.0.143
Password:
have a lot of fun
deo@victor:~/Documents>exit
deo@victor:~/Documents>ssh localuser@192.168.0.143
Password:
have a lot of fun
deo@victor:~/Documents>exit

еще один опыт:

Код: Выделить всё

# /etc/hosts.allow
sshd: @nonExistingNetgroup

Код: Выделить всё

deo@victor:~/Documents> ssh user@192.168.0.143
ssh_exchange_identification: Connection closed by remote host
deo@victor:~/Documents> ssh user2@192.168.0.143
ssh_exchange_identification: Connection closed by remote host
deo@victor:~/Documents> ssh localuser@192.168.0.143
ssh_exchange_identification: Connection closed by remote host

# Entry 1: cn=test,ou=netgroups,dc=virtual
dn: cn=test,ou=netgroups,dc=virtual
cn: test
nisnetgrouptriple: (,user,)
objectclass: nisNetgroup
objectclass: top

или что-то еще недокручено, что эта группа раздается всем, кому ни попадя?

[Ленивая Бестолочь]

посмотрите getent passwd - у вас точно uid у всех юзеров разные?

[Deo]

1000, 1001 и 1002.

[Ленивая Бестолочь]

разобрался: к сожалению с /etc/hosts.* сейчас через нетгруппы можно контроллировать только доступ по хостам. извините, что ввёл в заблуждение :-)
предлагают такой (проверил) вариант:
в файле /etc/pam.d/sshd, или аналогичном нужно иметь строку:

Код: Выделить всё

account  required     pam_access.so

далее в файле /etc/security/access.conf
добавляете такое:

Код: Выделить всё

+ : root : ALL
+ : @sysadmin : ALL
- : ALL : ALL

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

если /etc/security/access.conf используется ещё для чего-либо и не хочется его менять, то можно создать ещё один файл и указать его параметром в pam.d:

Код: Выделить всё

account  required     pam_access.so accessfile=/path/to/access.conf

и да, я так понимаю, что, для того, чтобы использовать разделение на домены, нужно где-то задать имя домена нис. в редхатоподобных пишут, что в /etc/sysconfig/network, в дебиане должно быть /etc/defaultdomain, но чет не работает :-)
триплеты без доменов, типа ( , username, ) работают хорошо.

[Deo]

Спасибо, я уже дома, в понедельник попробую.
Из того, что за сегодня понапрочитал, сделал вывод: ldap рулит во всех смыслах и при любом ударении.

[Ленивая Бестолочь]

Deo, не за что. удачи вам.
да, лдап - это хорошо.


update.
я проспался и решил написать две вещи:

1. раз мы дошли до использования pam_access, то возникает разумная мысль просто напихать в access.conf обычных групп из лдапа (не нетгруп), самый простой вариант: две группы по типу:

Код: Выделить всё

+ : server1_access_allow : ALL
- : server1_access_deny : ALL

и соответственно одной разрешить доступ, а другой запретить.
да, это будет работать.

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

Код: Выделить всё

# sysadmin, Netgroups, raccoonia.org
dn: cn=sysadmin,ou=Netgroups,dc=raccoonia,dc=org
objectClass: nisNetgroup
objectClass: top
cn: sysadmin
nisNetgroupTriple: (,sasha,domain1)
nisNetgroupTriple: (petya_ws,petya,domain1)
nisNetgroupTriple: (,sasha,domain2)

в этом примере у нас есть админ sasha, которому можно ходить на все хосты (у которых эта нетгруппа разрешает вход, конечно же) в доменах domain1 и domain2, а так же есть админ petya (видимо криворукий), которому можно только в domain1 и только со своего компьютера (petya_ws).

2. пока вы ещё только начинаете внедрять лдап я очень рекомендую вам перейти на использование rfc2307bis, который позволяет использовать dn в качестве члена группы, вот так примерно:

Код: Выделить всё

# gr, Groups, raccoonia.org
dn: cn=gr,ou=Groups,dc=raccoonia,dc=org
objectClass: groupOfNames
objectClass: posixGroup
cn: gr
gidNumber: 10001
description: Group account
member: uid=user1,ou=Users,dc=raccoonia,dc=org

это нам что даёт:
- вложенные группы

Spoiler

ПРЕСВЯТЫЕ МАКАРОНЫ, ЭТО ЖЕ ВЛОЖЕННЫЕ ГРУППЫ!

- более быструю работу ldap (нет необходимости делать более сложный поиск, т.к. dn члена группы есть сразу же)
- сильно более быструю работу самбы (необходимо сто раз прочитать man smb.conf перед настройкой)
- возможность отказаться от ldapscripts или smbldap-tools при использовании самбы
- возможность включть группы пользователей и группы хостов в нетгруппы (сам не пробовал, т.к. не надо было)
- дополнтельный геморой при администрировании ручками. ну, тут вопрос в том, кто чем ковыряется в лдапе.

пример вложенных групп:

Код: Выделить всё

root@debian-1:/etc/ldap/schema# ldapsearch -LLL  -b dc=raccoonia,dc=org -c -y /etc/ldapscripts/ldapscripts.passwd -D cn=admin,dc=raccoonia,dc=org -xH ldap://localhost '(objectClass=posixGroup)'
dn: cn=gr,ou=Groups,dc=raccoonia,dc=org
objectClass: groupOfNames
objectClass: posixGroup
cn: gr
gidNumber: 10001
description: Group account
member: uid=user1,ou=Users,dc=raccoonia,dc=org
member: uid=user2,ou=Users,dc=raccoonia,dc=org

dn: cn=gr2,ou=Groups,dc=raccoonia,dc=org
objectClass: groupOfNames
objectClass: posixGroup
cn: gr2
gidNumber: 10002
description: Group account
member: uid=user3,ou=Users,dc=raccoonia,dc=org
member: uid=user4,ou=Users,dc=raccoonia,dc=org

dn: cn=gr3,ou=Groups,dc=raccoonia,dc=org
objectClass: groupOfNames
objectClass: posixGroup
cn: gr3
gidNumber: 10003
description: Group account
member: cn=gr,ou=Groups,dc=raccoonia,dc=org
member: cn=gr2,ou=Groups,dc=raccoonia,dc=org

как это видно:

Код: Выделить всё

root@debian-2:~# getent group | grep gr
nogroup:x:65534:
gr:*:10001:user1,user2
gr2:*:10002:user3,user4
gr3:*:10003:user1,user2,user3,user4
root@debian-2:~#

[Deo]

Все завелось. Буду красноглазить дальше :)

В Сусе rfc2307bis по умолчанию, из-за этого и был косяк с темплейтами для phpldapadmin.
Сейчас повторяю все это на дебиане, покурю как добавить rfc2307bis.

апд. Дебиан повел себя как подлец. 3 часа парил мне мозги неправильно захешированным паролем. ((

[Deo]

c rfc2307bis что-то не очень.

Код: Выделить всё

~mkdir /tmp/eee
~#slapcat -f sc.conf -F /tmp/eee -n0 -s "cn={2}rfc2307bis,cn=schema,cn=config" > /tmp/cn=rfc2307bis.ldif

~ldapadd -x -D cn=admin,cn=config -W -f /tmp/cn\=rfc2307bis.ldif
Enter LDAP Password:
adding new entry "cn=rfc2307bis,cn=schema,cn=config"
ldap_add: Other (e.g., implementation specific) error (80)
        additional info: olcAttributeTypes: Duplicate attributeType: "1.3.6.1.1.1.1.2"

строка там такая:

Код: Выделить всё

olcAttributeTypes: {0}( 1.3.6.1.1.1.1.2 NAME 'gecos' DESC 'The GECOS field; th
 e common name' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatc
 h SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

пробовал удалить схему nis. Тоже никак:

Код: Выделить всё

ldapdelete -vxW -D 'cn=admin,cn=config' 'cn={2}nis,cn=schema,cn=config'
Enter LDAP Password:
deleting entry "cn={2}nis,cn=schema,cn=config"
ldap_delete: Server is unwilling to perform (53)

[Ленивая Бестолочь]

пробовал удалить схему nis. Тоже никак:

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

additional info: olcAttributeTypes: Duplicate attributeType: "1.3.6.1.1.1.1.2"

после удаления nis схемы надо глянуть.


тут ещё проблема в том, что до удаления схемы nis нужно убрать из лдапа всё, что её использует. то есть всех юзеров и групп.

апд. Дебиан повел себя как подлец. 3 часа парил мне мозги неправильно захешированным паролем. ((

эээ. что-то это странно...

[Deo]

Переименовал схему в JXplorer, руками исправил значения атрибутов, добавил недостающие. Все подхватилось.
Поднял ldaps.
Курощаю убунту-клиента по ssl. Идет довольно муторно, с Suse было проще. Может потому, что я усложнил задачу - кроме SSL закрыл доступ анонимусу и создал прокси-аккаунт для чтения

[Deo]

едет крыша. Попробовал подключить как адресную книгу к почтовикам.
Без шифрования на 389 порту - все ок.
thunderbird 14 говорит, что там 0 контактов. Но автодополнение адресов есть, загрузка адресной книги с вкладки Offline дает "Replication success". Словом, все счастливы.

Порт 636 (SSL/TLS). Тут начинаются приключения. Evolution все так же корректно показывает записи из ou=people,dc=server,dc=com
thunderbird все так же 0 контактов. Правда автодополнения адресов нет, загрузка адресной книги с вкладки Offline дает "Replication failed"

нагуглил

Код: Выделить всё

export NSS_SSL_CBC_RANDOM_IV=0

не помогло

пускал с

Код: Выделить всё

export NSPR_LOG_MODULES=ldap:5;export NSPR_LOG_FILE=/home/deo/log

и даже, отчаявшись

Код: Выделить всё

export NSPR_LOG_MODULES=all:5;export NSPR_LOG_FILE=/home/deo/log

в логе ничего крамольного. Биндим-анбиндим.
Но с SSL не ищет, без SSL - ищет. Пойду на форумы Мозиллы мозги полоскать.

[Ленивая Бестолочь]

thunderbird 14 говорит, что там 0 контактов. Но автодополнение адресов есть, загрузка адресной книги с вкладки Offline дает "Replication success". Словом, все счастливы.

если честно, я не помню, где tb говорит, сколько в книге контактов, но, если речь о том, что "открываешь книгу, а там пусто" - то это нормальное поведение tb. типа ищите поиском, и тогда появится, или пользуйтесь автодополнением. даже если там 3,5 контакта ).
он вроде бы и для AD тоже так себя ведёт.

Но с SSL не ищет, без SSL - ищет. Пойду на форумы Мозиллы мозги полоскать.

расскажите, что получилось потом.
у нас была схожая проблема с ssl, thunderbird и dovecot, но не по части книги, а с imap.

[Deo]

моя проблема решилась.У меня был self-signed сертификат, а в ТБ "Нельзя просто так взять и импортировать ССЛ сертификат" (боромир.жпг)
Нужно потом еще в списке сертификатов нажать кнопку "Edit trust" и поменять на "Do not trust" на "Trust"


что касается SSL - это я нагуглил еще вчера. Начиная с 10й версии в ТБ закрыли дыру самого SSL и он не может соединятся по SSL с серверами, где эта дыра не закрыта.
Проверить можно, установив перед запуском сандербёрда переменную окружения NSS_SSL_CBC_RANDOM_IV в 0. Если он в такой конфигурации подключается, то нужно апгрейдить сервер.

IMAP SSL/TLS Server don't work after TB9->TB10 upgrade due to IMAP servers that haven't fixed an old SSL bug that TB10/FF10 fixed (similar issue to the LDAP issue in bug 723551); So far this SSL bug has only manifested itself in IceWarp aka Merk mail servers and might be an IceWarp 10.3.5-only issue so a support ticket was filed with Merk :[GS1]; [bug 723109] which apparently is a dup of: bug 702111; WORKAROUND: "create a batch file that sets NSS_SSL_CBC_RANDOM_IV=0 and then runs Thunderbird"

отсюда https://wiki.mozilla.org/Thunderbird/Thunde....0SupportIssues

[Deo]

каждому, кто пойдет моим путем, рекомендую связку

nslcd libpam-ldapd libnss-ldapd

настройка более простая и гибкая.

например, для задания нелокальным пользователям домашних каталогов, отличных от каталогов локальных пользователей.

map passwd homeDirectory "/home/remote/$uid"

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