SSSD/ssh-public-keys: различия между версиями

Материал из ALT Linux Wiki
(Новая страница: «У службы SSSD есть множество интересных возможностей востребованных в корпоративной среде. К примеру, хранение sudo правил непосредственно в LDAP либо хранение публичных ssh ключей системных администраторов. Итак, суть задачи - есть системный админ...»)
 
м (я осел потому что уже писал аналогичную статью)
 
Строка 1: Строка 1:
{| style="border:1px solid #AAA; background:#F9F9F9; width:200px; margin: 0 0 1em 1em; padding:.2em; text-align:center; float: right;" class=noprint
|-
|[[Изображение:Edit-cut.svg]]
|-
| '''Дубликат статьи [[Ssh/Domain]]. Будет удален в октябре 2024 г.'''
|}
У службы SSSD есть множество интересных возможностей востребованных в корпоративной среде.
У службы SSSD есть множество интересных возможностей востребованных в корпоративной среде.
К примеру, хранение [[Sudo/Domain|sudo]] правил непосредственно в LDAP либо хранение публичных ssh ключей системных администраторов.
К примеру, хранение [[Sudo/Domain|sudo]] правил непосредственно в LDAP либо хранение публичных ssh ключей системных администраторов.

Текущая версия от 13:54, 25 сентября 2024

Edit-cut.svg
Дубликат статьи Ssh/Domain. Будет удален в октябре 2024 г.

У службы SSSD есть множество интересных возможностей востребованных в корпоративной среде. К примеру, хранение sudo правил непосредственно в LDAP либо хранение публичных ssh ключей системных администраторов.

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

На рабочем месте администратора генерируем (если их еще нет) ключи

[domain-admin@work-pc]$ ssh-keygen -t ed25519

Нас интересует публичная часть

[domain-admin@work-pc]$ cat /home/TEST.ALT/domain-admin/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIB0vPVTa/loMnYcpcd2gZbiKTiiIZTgsAXzOig0ybZVK domain-admin@work-pc

С помощью любых удобных средств (ldbadd/ldbmodify, либо admc в аттрибуте altSecurityIdentities учетной записи domain-admin )

altSecurityIdentities в ADMC

В консоли можно проверить содержимое путем запроса через ldapsearch (от Kerberos тикета текущего пользователя)

[domain-admin@work-pc]$ ldapsearch -LLL -Y GSSAPI -h dc.test.alt -b dc=test,dc=alt '(sAMAccountName=domain-admin)' altSecurityIdentities
SASL/GSSAPI authentication started
SASL username: administrator@TEST.ALT
SASL SSF: 256
SASL data security layer installed.
dn: CN=domain-admin,OU=DA,DC=test,DC=alt
altSecurityIdentities: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIB0vPVTa/loMnYcpcd2
 gZbiKTiiIZTgsAXzOig0ybZVK domain-admin@work-pc

На этом настройка серверной части завершена. Теперь необходимо настроить клиенты на получение службой sssd этих данных. Для этого, в /etc/sssd/sssd.conf на клиентах, в секции описания главного домена нужно добавить строки

ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities
ldap_user_ssh_public_key = altSecurityIdentities
ldap_use_tokengroups = True

И в конфиг службы sshd (/etc/openssh/sshd_config) добавить опции

AuthorizedKeysCommand  /usr/bin/sss_ssh_authorizedkeys %u
AuthorizedKeysCommandUser root

Теперь после перезапуска служб sssd, sshd доменный пользователь domain-admin будет подключатся к доменным хостам используя свой публичный ssh ключ.