☰

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

tag-icon • tag-icon ssh ldap samba autofs
Использование 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в posixUserLDAP).

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

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

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

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

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

решение1

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

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

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

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

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

решение2

Хотя я считаю, что ответ @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.

Возможно, это поможет кому-то еще.

Стив

Связанный контент