[Previo por Fecha] [Siguiente por Fecha] [Previo por Hilo] [Siguiente por Hilo]
[Hilos de Discusión] [Fecha] [Tema] [Autor]Efectivamente el uso de $HOME/.rhosts es un riesgo de seguridad (como lo estableci en el mail anterior), pero las cosideraciones hechas fueron pensando en un ambiente de red seguro(bueno la mas que se pueda) es decir, las 20 y tantas maquinas tuvieran ssh, desahabilitados los servicios r* (rlogin, rsh, etc) en /etc/inetd.conf, y como era un cluster tener el NIS++ instalado. Toda la consideracion es que solo se iba a usar ssh, y este reconoce ambos archivos .rhosts y .shosts, definitivamente el uso de .rhosts es un peligro si los servicios r* estan habilitados en alguna de esas maquinas, ya que es una puerta abierta. Por eso un vistazo al man ssh o al HOW-TO fue la recomendacion. Cierto el .shosts, al ser esclusivo para ssh, y este al tener un esquema de autentificacion de llave publica y privada, solo permite que 2 maquinas se interconecten sin passwd, si antes se hace una conexion de ida y de regreso entre ambas maquinas, esto con el fin de que ambas reconozcan las llaves publicas respectivas, y con esto certifiquen que el usuario que entra sin passwd efectivamente vienen de la maquina certificada. Sin embargo, la solucion que se planteo con puro uso de llaves publicas y privadas es tambien conveniente. Y por cierto tambien sirve para ssh(ademas del ss2) solo habia que hacer 1 o 2 consideraciones diferentes. Lo prove y jalo. Bye. On Wed, 26 Jul 2000, Salvador Ortiz Garcia wrote: > Efectivamente $HOME/.rhosts y /etc/hosts.equiv, como parte de los > servicios r* (rsh, rcmd, rlogin) (todos basados en rcmd(3)) basan su > seguridad en un antiquisimo esquema de "puertos reservados" (512-1023) que > data de tiempos en que la cofradía de los superusuarios "root" era > limitada, pequeñita y sus miembros se llevaban de piquete de ombligo > (4.2BSD). > > Esquema que para todo fín práctico ya no sirve de nada pues, como dirán > algunos hoy cualquier escuincle "despistado" puede ser "root" y en > realidad hay millones de máquinas con TCP/IP que no tienen ni noción de > root (cf. MS Windows). > > Al margen de que existen implementaciones de los servicios r* que son > Kerberos dependientes y donde la cosa es suficientemente segura, de plano > mejor comentar los servicios correspondientes en el inetd.conf. > > En el caso de ssh, la cosa cambia pues si bien está modelado para ser rsh > compatible y puede como última posibilidad usar ése protocolo, en su > documentación encontramos que: > > Rhosts authentication is normally disabled because it is > fundamentally insecure, but can be enabled in the server > configuration file if desired. System security is not > improved unless rshd(8), rlogind(8), rexecd(8), and rexd > (8) are disabled (thus completely disabling rlogin(1) and > rsh(1) into that machine). > > En ssh el uso de $HOME/.shosts o /etc/ssh/shosts.equiv es mucho más > seguro pues la identidad de las máquinas que intervienen en la conexión > está asegurada por sus respectivas llaves criptográficas. > > De forma que en un ambiente controlado (es decir en que todas las máquinas > sean igualmente seguras) puede ser muy util si además las cuentas de los > usuarios son comunes via NIS, LDAP, etc. > > En ambientes más abiertos (p.e. La Internet), con ssh es mejor depender de > las llaves criptográficas de los usuarios individuales. > > Saludos > > Salvador Ortiz > > > -- > El conocimiento incluído es totalmente regalado y como Linux, libre. > -------------------------------------------------------------------------- > > > --------------------------------------------------------- > para salir de la lista, enviar un mensaje con las palabras > "unsubscribe ayuda" en el cuerpo a majordomo en linux org mx > --------------------------------------------------------- para salir de la lista, enviar un mensaje con las palabras "unsubscribe ayuda" en el cuerpo a majordomo en linux org mx