☰

Usando LDAP: ¿cómo iniciar sesión con SSH, montando el directorio de inicio de Samba con autofs?

tag-icon • tag-icon ssh ldap samba autofs
Usando LDAP: ¿cómo iniciar sesión con SSH, montando el directorio de inicio de Samba con autofs?

He dedicado algún tiempo a configurar la autenticación basada en LDAP en mi red MacOS, iOS y Linux, teniendo en cuenta las peculiaridades especiales de MacOS y Synology (mi NAS). El inicio de sesión SSH (claves SSH, etc.) funciona y los montajes compartidos de Samba funcionan. Todo fue bastante complicado y ahora sé más sobre LDAP de lo que jamás anticipé.

Sin embargo...

Habiendo llegado a un punto en el que podía (al menos en teoría) iniciar sesión en cualquier máquina de mi red, pensé que sería bueno que los usuarios también tuvieran acceso al mismo directorio de inicio en todas partes. No hay problema: autofs¡que también se puede gestionar desde LDAP! O eso pensé...

Estoy intentando algo como lo siguiente para configurar los directorios de inicio de Samba para 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

Algunos antecedentes:

  1. s-sy-00.locales mi Synology NAS donde residirán los directorios de inicio.
  2. /homees UNC del recurso compartido del directorio principal que Synology ofrece para el usuario definido en username=.

Los problemas comienzan cuando inicio sesión en una máquina remota con SSH. autofsintenta montar el directorio de inicio del usuario, pero necesita la contraseña del usuario. Puedo poner la contraseña en un password=parámetro en la automountInformationlínea, o puedo poner el nombre de usuario y la contraseña en un archivo de credenciales que paso con el credentials=parámetro. Ambos enfoques generan complejidad adicional (una automountentrada para cada usuario) y duplicación (mismo nombre de usuario y contraseña en dos lugares diferentes: LDAP y el archivo de credenciales o el automounty el posixUseren LDAP).

¿Existe una forma estándar de abordar este problema? Mis habilidades con los motores de búsqueda no han arrojado nada todavía.

Me parece que hay tres posibles soluciones:

  1. el que es obvio para todos los demás pero no para mí;
  2. usar la clave SSH para montar un archivo de credenciales por usuario (posiblemente generado dinámicamente desde LDAP) desde un recurso compartido SSHFS;
  3. usando Kerberos para un SSO completo.

Preferiría el número 1 :-) Tengo aversión a Kerberos: parece excesivo y ciertamente es relativamente complejo.

¿Alguien puede ofrecerme algunas palabras sabias que me ayuden a comenzar el nuevo año con buen pie?

Respuesta1

Bueno, siempre y cuando estés en Linux y usescontraseñaautenticación para el inicio de sesión inicial, entonces puede tener un módulo PAM que guarda la contraseña en un llavero del kernel donde mount.cifs puede recogerla. No estoy 100% seguro de si cifs-utils viene con uno actualmente, pero tiene una cifscredsherramienta CLI que hace lo mismo.

Aún así, personalmente configuraría la autenticación Kerberos en lugar de LDAP. (Es decir, dejar que LDAP haga sólo el trabajo de un servicio de directorio). En general, Kerberos es como LDAP: parece complejo desde fuera, pero resulta muy simple cuando se mira más de cerca, excepto por los millones de peculiaridades, casos extremos y decisiones extrañas que se remontan a la década de 1980 y que lo vuelven complejo nuevamente.

Será un poco más versátil que los hacks PAM específicos para SMB: se pueden usar los mismos tickets para acceder a SMB, NFS, LDAP, HTTP, SSH... Incluso puedes reutilizar tu servidor LDAP existente como backend de la base de datos KDC, obteniendo replicación gratuita sin tener que lidiar con kprop.

Tenga en cuenta que con mount.cifs,ambosKerberos y cifscreds están pensados ​​para usarse al montar el recurso compartido con la multiuseropción, que le brinda un comportamiento similar a NFS: varios usuarios pueden acceder al mismo montaje SMB y el kernel usará automáticamente las credenciales SMB correctas para cada uid.

Y en cuanto a la autenticación de clave pública SSH, no hay mucho que pueda hacer automáticamente: o recupera un archivo de credenciales y lo usa con cifscreds, o recupera un archivo de credenciales y lo usa con kinit... Nuevamente, creo que esto último es más versátil.

Respuesta2

Aunque creo que la respuesta de @user1686 es la correcta, todavía me gustaría compartir la solución alternativa que encontré y que usaré hasta que pueda encontrar tiempo para pasar a una solución Kerberos.

  1. Creé un usuario en el NAS al que llamé smbownery le asigné una contraseña. Le otorgué smbownerderechos de administrador al NAS, lo que significa que puede montar un recurso compartido SMB.

  2. Creé un archivo de credenciales de Samba en la máquina que necesitaba montar el recurso compartido SMB. Lo puse /etc/samba/credentials/s-sy-00y se ve así:

username=smbowner
password=whatever

Tenga en cuenta que el archivo de credenciales no contiene una definición de dominio.

  1. Cambié la entrada LDAP a la siguiente:
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/&

En su defensa, se puede decir que esta solución funciona, aunque no estoy seguro de qué tan segura sería en un entorno más hostil que el mío.

¿Como funciona? smbownertiene permisos suficientes para montar cualquier recurso compartido en el NAS. Los parámetros uid=&y gid=&garantizan que el recurso compartido sea accesible para el usuario local. Experimentaré más adelante con la configuración de permisos para compartir en el NAS.

Quizás esto ayude a alguien más.

esteban

información relacionada