LINUX.ORG.RU

Как сделать OpenLDAP SSH авторизацию юзеров через публичный ключ с PAM ?

 , ,


1

1

И так сервак OpenLDAP. На него добавлена схема dn: cn=openssh-lpk,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: openssh-lpk
olcAttributeTypes: ( 1.3.6.1.4.1.24552.500.1.1.1.13 NAME 'sshPublicKey'
DESC 'MANDATORY: OpenSSH Public key'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
olcObjectClasses: ( 1.3.6.1.4.1.24552.500.1.1.2.0 NAME 'ldapPublicKey' SUP top AUXILIARY
DESC 'MANDATORY: OpenSSH LPK objectclass'
MAY ( sshPublicKey $ uid )
)

ldapadd -Y EXTERNAL -H ldapi:/// -f openssh-lpk.ldif
на юзера добавлен ключ.

На клиенте: /etc/ldap.conf
--- base dc=test
uri ldap://ldap.test
ldap_version 3
rootbinddn cn=admin,dc=test
pam_password md5

### /etc/nsswitch.conf
---- passwd: ldap compat
group: ldap compat
shadow: ldap compat

hosts: files dns
networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

netgroup: nis

#### /etc/pam.d/common-session
------- session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session optional pam_umask.so
session required pam_unix.so
session optional pam_ldap.so
session optional pam_systemd.so
session required pam_mkhomedir.so skel=/etc/skel umask=0022


И дальше самое интересное для того что бы при авторизации клиент брал данные о ключе я довил скрипт с ldapsearch который тянет из базы ключ и в sshd добавил его вызов.

НО! В это случае с авторизацие по ключу абсолютно игнорятся все лимиты в /etc/security/access.conf


Вопрос: Как сделать так что бы и авторизация по ключу работала и лимитировать по группам вход можно было.

LDAP тут вообще ни при чем.
Кто занимается проверкой access.conf? Правильно - pam_access.
А где у тебя нахоится pam_access в конфиге PAM? Видимо, в стеке auth. А вот это неправильно. Надо, чтобы он был в стеке account, тогда он будет вызываться при заходе по ключу.

bigbit ★★★★★ ()
Ответ на: комментарий от bigbit

воистуну прав. надо было добавить
account required pam_access.so
в /etc/pam.d/common-account

mercenaris ()
Ответ на: комментарий от bigbit

но есть еще баг или фича..... access.conf все лимитирует НО он дает лимити только на юзеров или на GID пример, если в access.conf
+ : ssh_access (ssh_access) : ALL
- : ALL : ALL

И юзер
uid=2003(ttest3) gid=502(developers) groups=502(developers) он его пустит, а не должен

если юзать
+ : ssh_access : ALL
- : ALL : ALL
пустить в случает
uid=2003(ttest3) gid=502(ssh_access) groups=502(developers) но проигнорит
uid=2003(ttest3) gid=502(developers) groups=502(ssh_access)
то есть группы он напрочь игнорит.

в оф. доке написано что надо в скобки ставить , но япробовал и + : ssh_access : ALL
и
+ : (ssh_access) : ALL
и
+ : ssh_access (ssh_access) : ALL
и
- : ALL EXCEPT root (ssh_access):ALL EXCEPT LOCAL

никак не хочет работать

mercenaris ()
Ответ на: комментарий от bigbit

к примеру при конфиге

+ : ubuntu : ALL
+ : ssh_access : ALL
- : ALL : ALL

и юзере uid=2003(ttest3) gid=502(developers) groups=502(ssh_access)

выдаст ошибку auth.log
fatal: Access denied for user ttest by PAM account configuration [preauth]

mercenaris ()
Ответ на: комментарий от mercenaris

gid=502(developers) groups=502(ssh_access)

Не понял. У тебя что, несколько разных групп с одинаковым GID?
Это хрень какая-то.

bigbit ★★★★★ ()
Ответ на: комментарий от bigbit

нет, юзер же может состоять в нескольких группах, но access.conf обрезает политики входа только обращая внимания на мейн группу то есть gid.

А то что идет в groups он не парсит вообще. Вот и вопрос как это пофиксать.

mercenaris ()
Ответ на: комментарий от bigbit

пример просто скопировал не правильно,

индентификаторы уникальные.

mercenaris ()
Ответ на: комментарий от bigbit

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

mercenaris ()
Ответ на: комментарий от bigbit

проблемка решена, надо или убрать кеш, или поставить его малым к примеру 30с.

есть еще каверзный вопрос. как ограничить лимит доступа по ssh по группам сервером.

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

Но может есть какой то более красивый способ ?

mercenaris ()
Ответ на: комментарий от mercenaris

Так и делают обычно.
Можешь еще в сторону нетгрупп (netgroup) посмотреть - их можно впендирить прямо в /etc/passwd, чтобы система видела только тех пользователей, которые в нетгруппе: +@netgroup:x:::::

bigbit ★★★★★ ()
Ответ на: комментарий от bigbit

нетгруппы атавизмом каким то попахивают :)
ну да ладно, есть странная бажина еще на клиентской стороне. если в /etc/nsswitch.conf
стоит
passwd: ldap compat
group: ldap compat
shadow: ldap compat
то все работает НО система как то адски долго грузиться и не всегда, клауд инит выдает какието страшные цифра аля

Cloud-init v. 0.7.5 running 'modules:config' at Tue, 24 Oct 2017 15:09:59 +0000. Up 377.51 seconds.
Cloud-init v. 0.7.5 running 'modules:final' at Tue, 24 Oct 2017 15:10:31 +0000. Up 409.32 seconds.
Cloud-init v. 0.7.5 finished at Tue, 24 Oct 2017 15:10:31 +0000. Datasource DataSourceEc2. Up 409.39 seconds

если ldap compat поменять местами то система, лдап юзеров видеть не будет но зато грузиться нормально будет :)

может у кого идеи есть .

mercenaris ()
Ответ на: комментарий от bigbit

чот не до конца я понимаю глубину этих операция , может для тех кто в танке просветишь ?
пробовал этот метод но ldap юзеров не видит
я заюзал

passwd: compat [NOTFOUND=continue] ldap
group: compat [NOTFOUND=continue] ldap
shadow: compat [NOTFOUND=continue] ldap

завелось нормально

mercenaris ()
Ответ на: комментарий от mercenaris

Смысл в том, что нетгруппы позволяют ограничить видимость пользователей. Т.е. если пользователь не входит в определенную нетгруппу, то ОС будет вести себя так, как будто этого пользователя не существует вовсе, несмотря на то, что он есть в LDAP. Фактически, для нее этот пользователь и не будет существовать. Примерно как ldap_search_filter в sssd.

А так как сделал ты - «passwd: compat [NOTFOUND=continue] ldap» - искать в compat, а если не нашли - искать в LDAP - так ОС будет видеть всех пользователей, которые есть в LDAP, даже если их нет в неггруппах. Смысл использования compat и нетгрупп в этом случае теряется - пиши уж сразу «files ldap» тогда.

пробовал этот метод но ldap юзеров не видит

Я мог наврать =) Под рукой нет системы с нетгруппами, чтобы проверить. Возможно, нужно просто «passwd: compat». Но то, что «passwd_compat: ldap» - точно. Ну и group_compat и shadow_compat соответственно.

bigbit ★★★★★ ()
Ответ на: комментарий от bigbit

Скорее всего я не наврал, а ты просто плюсики в /etc/passwd не добавил - каких пользователей показывать системе.

bigbit ★★★★★ ()
Ответ на: комментарий от bigbit

С нетгруппами заморочно как то получаеться просто изкать локально а если нет то искать в лдапе проще как то, это же не одноразовая операция. Это же все конфижиться через «configuration manager» в мое случае папет. Под каждую группу серверов писать полиси геморно)

mercenaris ()
Ответ на: комментарий от bigbit

ну а вообще если похоливарить, то в чем плюсы sssd как механизма авторизации ?

mercenaris ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.