Вопросы Теги

Использование LDAP: как войти в систему с помощью SSH, смонтировать домашний каталог Samba с помощью autofs?

Я потратил некоторое время на настройку аутентификации на основе LDAP в моей сети MacOS, iOS и Linux, принимая во внимание особые особенности MacOS и Synology (мой NAS) . SSH-вход (SSH-ключи и т. Д.) Работает, а общие ресурсы Samba работают. Все это было довольно неудобно, и теперь я знаю о LDAP больше, чем я ожидал.

Однако ...

Достигнув точки, когда я могу (по крайней мере теоретически) войти в систему на любой машине в моей сети, я подумал, что было бы неплохо, если бы пользователи также имели доступ к одному и тому же домашнему каталогу везде. Нет проблем: autofs , которым также можно управлять из LDAP! Или я так подумал ...

Я пытаюсь настроить домашние каталоги Samba для autofs , примерно так: 

cn=*,ou=auto.home,cn=automount,cn=etc,dc=home,dc=arpa
cn: *
objectClass: automount
objectClass: top
automountInformation: -fstype=cifs,vers=3.0,domain=HOME,rw,username=&,uid=&,gid=& ://s-sy-00.local/home

Немного предыстории:

  1. s-sy-00.local - это мой Synology NAS, в котором будут размещаться домашние каталоги.
  2. / home - это UNC общего домашнего каталога, который Synology обслуживает для пользователя, указанного в username = .

Проблемы начинаются, когда я вхожу на удаленную машину с помощью SSH. autofs пытается смонтировать домашний каталог пользователя, но ему нужен пароль пользователя.Я могу поместить пароль в параметр password = в строке automountInformation , или я могу поместить имя пользователя и пароль в файл учетных данных, который я передаю с помощью credentials = параметр. Оба подхода приводят к дополнительной сложности (запись automount для каждого пользователя) и дублированию (одно и то же имя пользователя и пароль в двух разных местах: LDAP и файл учетных данных или automount и ] posixUser в LDAP).

Есть ли стандартный способ решения этой проблемы? Мои навыки поисковой машины еще ничего не нашли.

Мне кажется, что есть три возможных решения:

  1. тот, который очевиден для всех, но не для меня;
  2. использование ключа SSH для монтирования файла учетных данных для каждого пользователя (возможно, динамически сгенерированного из LDAP) из общего ресурса SSHFS
  3. с использованием Kerberos для полноценного единого входа.

Я бы предпочел номер 1 :-) Я испытываю отвращение к Kerberos: он кажется излишним и, безусловно, относительно сложным.

Может ли кто-нибудь предложить несколько мудрых слов, которые помогут мне быстро начать новый год?

1
задан 14 January 2021 в 22:49
2 ответа

Что ж, если вы работаете в Linux и используете аутентификацию с паролем для первоначального входа в систему, тогда у вас может быть модуль PAM, который хранит пароль в связке ключей ядра, откуда mount.cifs может его забрать. Я не уверен на 100%, поставляется ли cifs-utils с ним в настоящее время, но у него есть инструмент CLI cifscreds , который делает то же самое.

Тем не менее, лично я бы просто установил аутентификацию Kerberos вместо LDAP. (То есть, оставляя LDAP выполнять только работу службы каталогов.) В целом Kerberos похож на LDAP: выглядит сложным снаружи, оказывается очень простым, если присмотреться, за исключением миллиона причуд, крайних случаев и странные решения 1980-х годов, которые снова усложняют ситуацию.

Он будет немного более универсальным, чем хаки PAM для SMB - те же билеты можно использовать для доступа к SMB, NFS, LDAP, HTTP, SSH ... Вы даже можете повторно использовать существующий сервер LDAP в качестве базы данных KDC. backend, получая репликацию бесплатно без необходимости иметь дело с kprop.

Обратите внимание, что с mount.cifs, и Kerberos, и cifscreds предназначены для использования при монтировании общего ресурса с опцией multiuser , которая дает вам поведение, подобное NFS - то же самое К монтированию SMB могут получить доступ несколько пользователей, и ядро ​​автоматически будет использовать правильные учетные данные SMB для каждого uid.

А что касается аутентификации с открытым ключом SSH, вы мало что можете сделать автоматически - либо вы получаете файл учетных данных и используете его с cifscreds , либо вы получаете файл учетных данных и используете его с ] kinit ... Опять же, последнее более универсально.

1
ответ дан 24 April 2021 в 00:49

Хотя я считаю, что ответ @ user1686 является правильным, я все же хотел бы поделиться с вами обходным решением, которое я нашел и буду использовать, пока не найду время для перехода на решение Kerberos.

  1. Я создал пользователя на NAS, которого назвал smbowner , и назначил ему пароль. Я дал smbowner права администратора на NAS, что означает, что он может монтировать общий ресурс SMB.

  2. Я создал файл учетных данных Samba на машине, которая требовалась для монтирования общего ресурса SMB. Я помещаю его в / etc / samba / credentials / s-sy-00 , и он выглядит так: 

username=smbowner
password=whatever

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

  1. Я изменил запись LDAP на следующее: 
cn=*,ou=auto.home,cn=automount,cn=etc,dc=home,dc=arpa
cn: *
objectClass: automount
objectClass: top
automountInformation: -fstype=cifs,vers=3.0,domain=HOME,rw,credentials=/etc/samba/credentials/s-sy-00,uid=&,gid=& ://s-sy-00.local/&

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

Как это работает? smbowner имеет достаточные разрешения для монтирования любого общего ресурса на NAS. Параметры uid = & и gid = & гарантируют, что общий ресурс доступен для локального пользователя. Позже я поэкспериментирую с настройками разрешений для общего ресурса на NAS.

Возможно, это поможет кому-то другому.

Стив

0
ответ дан 24 April 2021 в 00:49

Теги

Похожие вопросы