[Previo por Fecha] [Siguiente por Fecha] [Previo por Hilo] [Siguiente por Hilo]
[Hilos de Discusión] [Fecha] [Tema] [Autor]On Tue, 26 Feb 2002, David Alfredo Daza Padron wrote: > Bueno, ahi les va la solucion a mi problema > > resulta ser que por alguna extraña razon, en el directorio /dev se quedo > un archivo llamado random. Con tan solo borrarlo pude volver a utilizar > el ssh, generar llaves y todos los comandos del sshd, que simple manera > de arreglarlo no? > > gracias por sus comentarios. OUCH! /dev/random no se 'quedo' en tu computadora por una extra~a razon. Ahi reside de forma permanente, y es el dispositivo que proporciona datos aleatorios para el sano funcionamiento de tu sistema operativo. Al borrarlo, has eliminado la aleatoriedad de tu sistema, y reducido la seguridad de tu sistema a algo deterministico. ¿Qué significa esto? - Los numeros de las series que utiliza el subsistema de red de tu maquina se convirtieron en secuencias predeterminadas, y de repente, te volviste vulnerable a ataques de 'IP spoofing'. - Al carecer de aleatoriedad, las llaves criptograficas que produces son identicas y/o secuenciales, y por lo tanto decodificables sin tanto esfuerzo. Asi que la seguridad de SSH, GnuPG y de tus servidores que utilicen SSL y/o TLS no sirve. - Todas las contrase~as de tus usuarios se volveran debiles, porque crypt y MD5 necesitan una parte aleatoria para generar en cada invocacion una cadena diferente. - Si usas Kerberos, la informacion del 'ticket' generado es secuencial, y los elementos de seguridad que proporciona acaban en nada. - Si utilizas PPP + PAP/CHAP, tu sistema sin aleatoriedad se vuelve susceptible a que adivinen tu contrase~a. Y asi continua la lista... El otro sistema operativo que tiene una seguridad semejante a la que ofrece tu servidor es Window$ 95 :-) Solucion: Arranca en monousuario y ejecuta cd /dev MAKEDEV -v random Y despues, revisa las opciones de sshd_config, leyendo con calma la pagina de manual de sshd(8). Si no te gusta /dev/random, no lo borres y mejor utiliza `egd'. Moraleja: NO BORREN ARCHIVOS SIN SABER QUE FUNCIONALIDAD TIENEN! NO CAMBIEN LOS PERMISOS HASTA QUE SEPAN LO QUE HACEN! Me han tocado ver varios sistemas inutilizados por gente que borra lost+found o /tmp, o que 'incrementa' la seguridad de su sistema, quitando el 'sticky bit' de /usr/bin/passwd. No es gracioso. > Cristian Othon Martinez Vera wrote: > > > On Fri, 22 Feb 2002, David Alfredo Daza Padron wrote: > > > > > >>COmo andan jovenes, tengo un problema > >> > >>Resulta ser que ayer tube que reiniciar uno de mis servers por > >>questiones de mantto, al reiniciar, mi ssh2 no quizo > >>arrancar, me mandaba el siguiente error: > >> > >>sshd2[19717]:WARNING:AllowCshrcSourcingWith Subsystems Configuration > >>Keyword is deprecated. > >> > >>Alguno de uds le ha pasado algo similar? > >> > >>Ya reinstale los binarios de mi ssh, era la version 2.4.0, ya puse la > >>3.1.0, y nada, es la hora en que no puedo hacer que corra de nuevo mi > >>ssh. Por ultimo, me avente a compilar paso a paso el ssh2 y nada. sigue > >>igual.. OUT!!! > >> > >>Quize volver a generar mis llaves, y ni las llaves pude generar. > >> > >>Gracias espero sus respuestas. > >> > > > > Pues hazle caso al mensaje de error. :-) > > Comenta en el archivo de configuracion sshd.config la linea que contenga > > > > AllowCshrcSourcingWith > > > > para que funcione de nuevo. Saludos -- (o- Cristian Othon Martinez Vera <cfuga en itam mx> Pulchrum est paucorum //\ http://eniac.rhon.itam.mx/~cfuga/ hominum. v_/_ --------------------------------------------------------------------- Lista de soporte de LinuxPPP Reglas de la lista en http://linuxppp.com/reglas.html