On Tue, 25 Jun 2013 10:58:44 -0400 Damián Ilizastegui Arriba <dilizaste...@uci.cu> wrote:
> Hola: > > Es la llave privada del cliente la q se tiene q proteger, la llave > pública la puedes publicar en internet si quieres. > Pero es cierto, si alguien logra obtener la llave privada puede acceder > al servidor sin problemas. > Para resolver esto es q el ssh-keygen te pide un "passphrase", para > encriptar la llave privada y si alguien > la roba no pueda hacer nada. > Otra forma de añadir más seguridad es especificar desde q host se puede > conectar el cliente, que conjunto de > comandos puede ejecutar, si puede hacer X forward, etc. Esas cosas se > pueden configurar en el ssh (ahora mismo > me matas y no recuerdo dónde). Esto se configura en .ssh.authorized_keys para más info man ssh_config > > Generalmente se considera q la autenticación mediante llave > pública/privada es más segura. Principalmente > por hecho de que ni la llave, ni el password del usuario viajan nunca > por la red. Además que te evitas ataques de > diccionario y de fuerza bruta contra tu server ssh. > > slds; > > D. > > > > > > On 06/24/2013 06:20 PM, låzaro wrote: > > y después de eso, más te vale tener un iptables que solo permite el ssh > > DE tu maquina. > > > > Estamos hablando de un protocolo que da acceso total a tu servidor!!! > > > > ¿No les da miedo que ALGUIEN copie la clave publica? > > > > Realmente no creo en hackers de LAN pero no dormiría tranquilo pensando > > que alguien podría compiarse mi clave pública y hacer lo que le salga > > de su miembro en mi server sin que me entere. Considero una bonita > > costumbre, deshabilitar al root por ssh... así el que entre al server, > > hubiere de conocer, la contrasenha del usuario admin (un cualquiera para > > el ssh) y la contrasenha del root para poder hacer "su" (NO sudo) > > > > define: "seguridad" > > > > > > Thread name: "[Gutl-l] Evitar que nos pida autenticacion ssh" > > Mail number: 1 > > Date: Wed, Jun 19, 2013 > > In reply to: Jorge F Rdguez Hdez > >> Evitar que nos pida autenticacion el servidor SSH > >> > >> Siempre que intentemos conectarnos a un equipo remoto con SSH nos va a > >> pedir la contraseña de acceso para asegurarse de que tenemos acceso al > >> mismo. Hay una forma de evitar que nos pase eso siempre. Para ello hemos > >> de generar un par de llaves RSA y DSA las cuales sirven como claves de > >> autenticacion entre los dos equipos remotos. > >> > >> RSA > >> > >> Es un algoritmo asimétrico cifrador de bloques, que utiliza una clave > >> pública, la cual se distribuye en forma autenticada, y otra privada, la > >> cual es guardada en secreto por su propietario. > >> Los mensajes enviados usando el algoritmo RSA se representan mediante > >> números y el funcionamiento se basa en el producto de dos números primos > >> grandes mayores que 10100 elegidos al azar para conformar la clave de > >> descifrado. > >> > >> DSA (Digital Signature Algorithm) > >> > >> Es un estándar del Gobierno Federal de los Estados Unidos de América > >> para firmas digitales. Fue un Algoritmo propuesto por el Instituto > >> Nacional de Normas y Tecnología de los Estados Unidos para su uso en su > >> Estándar de Firma Digital. Este algoritmo como su nombre lo indica, > >> sirve para firmar y no para cifrar información. Una desventaja de este > >> algoritmo es que requiere mucho más tiempo de cómputo que RSA. > >> > >> El proceso para generar estas claves es el siguiente: > >> > >> Generación de claves RSA > >> > >> 1.-Teclee el siguiente comando desde una terminal BASH > >> [NOTA: El comando debe ejecutarse en el equipo cliente] > >> [root@ localhost ]# ssh-keygen -t rsa > >> > >> 2.-Al haber tecleado el comando este nos preguntara si queremos guardar > >> esa clave en otra ubicación, por defecto seleccionaremos la que nos da > >> por defecto > >> > >> 3.- Al haber aceptado nos pedirá introducir una contraseña y confirmarla > >> nuevamente > >> Enter passphrase (empty for no passphrase):xxxxxxxxxxxxxx > >> Enter same passphrase again: xxxxxxxxxxxxxxx > >> > >> 4.- Finalmente nos creara dos tipos de clave: > >> > >> ??? Una Publica, la cual sera almacenada en la ruta: > >> /home/administrador/.ssh/id_rsa.pub > >> ??? Una Privada, la cual sera almacenada en la ruta: > >> /home/administrador/.ssh/id_rsa > >> > >> Tras haber terminado de generar las claves nos tendrá que aparecer algo > >> similar a esto: > >> Your identification has been saved in /home/administrador/.ssh/id_rsa. > >> Your public key has been saved in /home/administrador/.ssh/id_rsa.pub. > >> The key fingerprint is: > >> c8:d1:10:62:52:1d:97:5d:7d:5a:d3:84:b5:24:48:3d > >> administrador@localdomain > >> > >> 5.- El siguiente paso sera cambiar los permisos de ejecución del > >> siguiente directorio /home/administrador/.ssh lo cual se hará de la > >> siguiente manera: > >> [root@ localhost ]# chmod 755 /home/administrador/.ssh > >> > >> 6.- Lo siguiente sera copiar el contenido del > >> fichero /home/administrador/.ssh/id_rsa.pub al > >> fichero /home/usuarioRemoto/.ssh/authorized_keys del equipo remoto. Si > >> este no existe no se preocupe, generelo con el uso del comando ???touch??? > >> y > >> pegue dentro de este el contenido del fichero. En caso de que el fichero > >> authorized_keys exista solo pegue el contenido del fichero id_rsa.pub > >> al fichero authorized_keys > >> > >> 7.- El siguiente paso sera cambiar los permisos de ejecución del > >> siguiente directorio remoto /home/usuarioRemoto/.ssh/authorized_keys lo > >> cual se hará de la siguiente manera: > >> [root@ localhost ]# chmod 644 /home/usuarioRemoto/.ssh/authorized_keys > >> > >> Con esto habremos concluido la generación de la clave RSA, ahora solo > >> nos falta generar la clave DSA > >> > >> Generación de claves DSA > >> > >> 1.-Teclee el siguiente comando desde una terminal BASH > >> [NOTA: El comando debe ejecutarse en el equipo cliente] > >> [root@ localhost ]# ssh-keygen -t dsa > >> > >> 2.-Al haber tecleado el comando este nos preguntara si queremos guardar > >> esa clave en otra ubicación, por defecto seleccionaremos la que nos da > >> por defecto > >> > >> 3.- Al haber aceptado nos pedirá introducir una contraseña y confirmarla > >> nuevamente_ > >> Enter passphrase (empty for no passphrase):xxxxxxxxxxxxxx > >> Enter same passphrase again: xxxxxxxxxxxxxxx > >> > >> 4.- Finalmente nos creara dos tipos de clave: > >> ??? Una Publica, la cual sera almacenada en la ruta: > >> /home/usuario/.ssh/id_dsa.pub > >> ??? Una Privada, la cual sera almacenada en la ruta: > >> /home/usuario/.ssh/id_dsa > >> > >> Tras haber terminado de generar las claves nos tendrá que aparecer algo > >> similar a esto: > >> Your identification has been saved in /home/administrador .ssh/id_dsa. > >> Your public key has been saved in /home/administrador/.ssh/id_dsa.pub. > >> The key fingerprint is: > >> 5d:7d:5a:d3:84:b5:24:48:3d:c8:d1:10:62:52:1d:97: > >> administrador@localdomain > >> > >> 5.- El siguiente paso sera cambiar los permisos de ejecución del > >> siguiente directorio /home/administrador/.ssh lo cual se hará de la > >> siguiente manera: > >> [root@ localhost ]# chmod 755 /home/administrador/.ssh > >> > >> 6.- Lo siguiente sera copiar el contenido del > >> fichero /home/usuario/.ssh/id_dsa.pub al > >> fichero /home/usuarioRemoto/.ssh/authorized_keys del equipo remoto. Si > >> este no existe no se preocupe, generelo con el uso del comando ???touch??? > >> y > >> pegue dentro de este el contenido del fichero En caso de que el fichero > >> authorized_keys exista solo pegue el contenido del fichero id_dsa.pub > >> al fichero authorized_keys > >> > >> 7.- El siguiente paso sera cambiar los permisos de ejecución del > >> siguiente directorio remoto /home/usuarioRemoto/.ssh/authorized_keys lo > >> cual se hará de la siguiente manera: > >> [root@ localhost ]# chmod 644 /home/usuarioRemoto/.ssh/authorized_keys > >> > >> Con esto habremos concluido la generación de las dos claves y de esa > >> manera ya no tendremos que autenticarnos cada vez que nos conectemos vía > >> SSH hacia algún equipo remoto > >> > > http://www.uci.cu > > -- > Este mensaje ha sido analizado por MailScanner > en busca de virus y otros contenidos peligrosos, > y se considera que está limpio. > > ______________________________________________________________________ > Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. > Gutl-l@jovenclub.cu > https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l -- Yoander Valdés Rodríguez <yoander.val...@gmail.com> -- Este mensaje ha sido analizado por MailScanner en busca de virus y otros contenidos peligrosos, y se considera que está limpio. ______________________________________________________________________ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l