Si, porque quiero controlar el acceso de los usuarios a cada nodo cliente del NIS y ademas evitar el acceso al servidor anulando la shell y el directorio home, por lo que en los clientes se han de añadir líneas de usuario especificando estos 2 campos. En cada cliente pogo como última linea:
Si tienes el NIS no necesitas hacer nada en los clientes para dar de alta
a los nuevos usuarios.
Yo utilizo el ssh, es lo más seguro (dentro de lo inseguro que es entrarDe acuerdo. Desde tu mensaje me he estado mirando detalladamente el ssh y hay varios aspectos que me gustaría comentar y que tu me confirmaras:
como root remotamente ;-). Cumple lo mismo que el rexec (creo) pero con
encriptación. Para ello tienes que configurar los clientes para que
admitan la utilización del fichero ~/.shost . Las opciones, relativas al
asunto, que tengo en el /etc/ssh/sshd_config de los clientes son:PermitRootLogin yes
IgnoreRhosts noy en fichero /root/.shost una línea con
servidor_principal root
entonces en cualquier scrip del servidor_principal puedo poner
directamente:/usr/bin/ssh servidor_secundario <comando que quiera>
1 - El .shost no es necesario para hacer entrada directa (sin password), pero si alguien consigue tu clave privada, puede entrar desde cualquier nodo y cualquier usuario, cosa que se impediría si se utiliza el .shost para expecificar el usuario y el nodo de procedencia
2 - El patch de ejecucion para una ejecución remota es /usr/bin:/bin:/usr/bin, y no he visto aún la manera de modificarlo: ni poniéndolo en $HOME/.ssh/rc, ni en $HOME/.ssh/environment, ni en $HOME/.bashrc, etc. Esto es importante en nuestro caso porque tengo 30 nodos (y subiendo) y cada vez que tenga que hacer apt-get install <paquete.deb> será un palo.
3 - Aun no he podido comprender la utilidad y el funcionamiento de ssh-agen/ssh-add. ¿Alquien me lo puede explicar?
4 - Vale, está muy bien esto de entrar directamente para poder ejecutar remotamente y tal y tal, pero intuyo que a medida que aumenta la facilidad/flexibilidad aumenta también la inseguridad. Si se puede atajar este problema estableciendo límites a esto en host.allow (solo acceso acceso sin password desde un nodo) pero me gustaría oir vuestras oponiones al respecto.
5 - Por otra parte este el tema de los password de root: ¿el mismo password en todos los sitios (cuando cambias solo lo has de hacer en un sitio) o tener un par (como mucho 3 diferentes) en funcion de si es el server, clientes de un tipo o clientes de un tipo diferentes?
6 - Por último y un poco desviándome del tema, ¿alguien
ha implementado una buena solución para centralizar password de
Unix y Windows: NIS por un lado y un PDC de samba (con la version 2.0.7
de samba al menos se pueden gestionar los accesos a un dominio) por otro,
crear una interface de usuario que cuando éste cambie el password
lo haga para los dos entornos. Una primera solución me la han apuntado
haciendo un CGI de perl utilizando apache-ssl para el tema de la comunicación
encriptada.
Pues mira, precisamente era un tema que tenía en cartera relaciona con un paquete llamado fai que sirve para clonar nodos en debian. A raiz de tu mensaje, me lo he estado mirando mas detalladamente e incluso he hecho una prueba de actualizacion del password de root en una serie de cliente. Este actualización es hecha secuencialmente por cada uno de los clientes a una señal del servidor y consiste en la substitucion de la line de root (la copia a saco de todo el /etc/passwd), puesto que en cada cliente no tiene porque haber el mismo /etc/passwd (de hecho, no lo hay). El cfengine tine capacidades de edición de ficheros yo diría que supero a la shell y el awk (no llega claro, al nivel de perl). Creo que es un software muy bueno y una alternativa más razonable (para muchos casos) a la ejecución remota.
Para configuración remota he oido que lo más pontente es el cfengine, pero
todavía no lo he mirado "ni por el forro".
Saludos a todos
-- Ramiro Alba Laboratori de Termotecnia i Energetica Departament de Maquines i Motors Termics ETS d'Enginyers Industrials de Terrassa C/Colom 11 Tf: 34 - 93 739 86 46 Fax: 34 - 93 739 81 01 e-mail: ramiro@labtie.mmt.upc.es