lunes, 30 de abril de 2012

Linux Mint Debian Edition (Una alternativa a Ubuntu)


LMDE, como es conocida, es una distribución de Mint basada en debian y no en ubuntu como suele ser habitual.

Esta distro que ahora está en su nueva versión 201204 (abril de 2012) es una versión muy particular...

Anteriormente ya había probado esta distro y hoy quiero expresar mi opinión sobre esta nueva versión.

Han optado por dos tipos de variantes... la variante con escritorio XFCE y la variante con MATE y CINNAMON, os hablaré de esta última.

Son escritorio basados en Gnome de distinta manera cada uno, pues mate es un fork de Gnome2 y cinnamon es un fork de Genome-shell.

Los forks son trabajos derivados de otros proyectos.... gnome decidió seguir con gnome3.
Al mismo tiempo, otras personas cogieron el código fuente de gnome2 para iniciar otro proyecto en paralelo para desarrollar otro escritorio... así nace mate.

Este es mate:

Mate es fork de gnome2 mientras que cinnamon más bien lo parece de unity... por ser un fork de gnome-shell :S

mate es espectacularmente rápido, y tiene integrado totalmente compiz en él...
pero he tenido algunos problemas.

(No os asustéis más abajo hay un enlace a otra entrada con los apaños para dejarlo perfect.)

Por ejemplo... hay un proceso que domina la decoración de ventanas llamado "marco" que cuando trabaja junto a compiz consume mucha CPU sin hacer absolutamente nada pues compiz usa su propio decorador de ventanas y chocan uno con otro...

Por otro lado, pongas como pongas la política de seguridad del anillo de claves... si networkmanager no se puede conectar a tu red wifi y te pregunta la clave wpa o wep... resulta que te la borra para que escribas de nuevo... y pierdes la clave original... un coñazo. (Parece solucionado)


Este es cinamon:

Cinnamon es muy intuitivo, facil de usar hasta para un niño y muy agradable en sus efectos de ventanas, me ha gustado la opción de añadir un gesto de ratón en la esquina superior izq para motrar los escritorios y las ventanas.... muy muy chulo,  pero es poco configurable... por otro lado, al ser un shell de gnome3 no es compatible con compiz.


Resulta que no todas las aplicaciones están en español.. como libreoffice o firefox.
Tampoco está activo el corrector ortográfico, ni para uno ni para otro....

Por otro lado, ya viene compiz configurado con muchos efectos añadidos.
Tiene todos los codecs necesarios para reproducir prácticamente todos los formatos de audio/video conocidos y soporte flash instalado por defecto.
También tiene activado la reproducción de DVD con lo que solo tenemos que usar como si nada.


La verdad, es una distro que promete, para mí, está algo verde con esos fork pero también veo verde a gnome3 y es una opinión personal.... sin duda me está dando el gusanillo y estos días la estoy probando a fondo... si veo que resulta migraré a este sistema. (De hecho... ya lo estoy haciendo)

Para que podáis arreglar todos esos problemas, que en realidad son pocos,  y dejar LMDE perfectamente y como nos gusta, he creado otra entrada:

http://pc-citos.blogspot.com.es/2012/05/lmde-punto.html

Un saludo a todos.

domingo, 15 de abril de 2012

Flisol, un gigantesco festival de software libre


Flisol es un festival de software libre que se celebrará el proximo 28 de abril a las 8:00 de la mañana  en la Universidad Nacional de Colombia, Bloque 25 (Artes)

Realmente es un evento al que toda persona interesada en este mundo o curiosa ha de acudir sin falta.
Se aprenderán muchas cosas y comprenderemos muchas otras que se relacionan con este mundo.








Mapa del sitio


Me han pedido que lo coloquéis en la biografia de facebook.

lunes, 2 de abril de 2012

SSH sin contraseña y de forma segura usando pareja de claves RSA

Hola a todos de nuevo, hoy voy a explicar de forma muy muy clara como funcionan las claves pública y privada. Ya verán como lo entienden.

Todos sabemos que ssh es un protocolo muy seguro, ya que todo la información que circula por la conexión entre cliente y servidor está encriptada.

Cuando hacemos una conexión a un servidor ssh lo hacemos así:

ssh usuario@direcion.ip.com

El servidor y el cliente ssh negocian el protocolo ssh que se usará (por seguridad debe ser la versión 2)
Y después generan un acuerdo de cifrado para el canal, de manera que ya todo lo que circule por él, esté cifrado.
La conexión continua..

Una vez abierto un canal seguro, el servidor nos pedirá contraseña para acceder y tras introducirla el servidor la comprobará.
Si la clave es correcta obtendremos acceso al servidor ssh.

Aquí se presentan dos inconvenientes.

1.- El password, aunque encriptado, viaja por la red cada vez que nos conectamos y esto puede ser peligroso si alguien estuviese capturando (snifando) datos de nuestra red y fuese capaz de generar fuerza bruta contra nuestros datos para sacar el pass.

2.- Tener que meter una y otra vez la clave cuando iniciamos sesión es 'cansino' y además, si tenemos 20 servidores y los que acceder.... Tenemos que tener 20 claves diferentes, ya que si usamos una sola para todo compromete la seguridad de los 20 pcs si perdemos la clave o alguien nos la roba.

Para todo esto hay una solución, usar un par de claves RSA.




Explicación sobre pareja de claves RSA

¿Que es RSA?
RSA es un sistema de encriptado que usa un algoritmo imposible de solucionar a día de hoy. Se creé que con la llegada de sistemas cuánticos y su rapidez se puedan llegar a solucionar.

¿Por qué una pareja?
Esto mucha gente no lo entiende, y lo voy a explicar muy claro.

Es una pareja de claves porque se crean a pares y de forma que una no sirve sin la otra, una clave es privada y la otra pública.

Clave privada:
Se usa para desencriptar y es la que debe estar solo presente en la máquina cliente y protegerla.

Clave  pública:
Se usa para encriptar y se puede repartir sin miedo a tus amigos.
Esta clave solo encripta y no puede usarse para desencriptar ni lo que se haya encriptado con ella.
Solo la clave privada asociada a ella puede desencriptar lo que se haya encriptado con la clave pública.


¿Y como funciona?
El proceso es el mismo pero con una diferencia...

ssh usuario@direcion.ip.com


El servidor y el cliente ssh negocian el protocolo ssh que se usará (por seguridad debe ser la versión 2)
Y después generan un acuerdo de cifrado para el canal, de manera que ya todo lo que circule por él, esté cifrado.

La conexión continua..
Hasta aquí todo igual, pero ahora comienza la diferencia.....:

El cliente decide usar RSA para identificarse, así que le manda al servidor información sobre su clave pública..

El servidor busca en su base da datos en busca de la clave pública del cliente, cuando la encuentra le manda un desafío, si si, como lo oyes. El servidor manda un paquete llamado (challenge) que contiene un número aleatorio cifrado con la clave pública del cliente.

El cliente recibe el paquete encriptado y usa la clave privada para desencriptar el mensaje, una vez desencriptado se lo devuelve al server... y le dice "¡Eh mira, lo he averiguado, así que soy yo!".

El servidor comprueba que el número devuelto es igual que el que mandó encriptado y por tanto el usuario es el que dice ser, ya que ninguna otra persona puede desencriptar el paquete sin no tiene la clave privada asociada a la pública. Así que se permite la sesión.

Yo creo que explicado así se entiende a la perfección.

¿Os habéis fijado que en ningún momento se mandan claves por la red?
Ahora podrías dar a todos tus amigos tu cláve pública y así poder entrar en sus sistemas sin pedir contraseña ni tener que usar una contraseña para cada sitio.

Como podréis imaginar, si alguien os copia la clave privada de vuestro ordenador, podrá acceder a cualquier sistema en el que estén la clave pública..... que peligro ¿no?
Tranquilos, generaremos una clave RSA que esté encriptada con clave, de manera que si alguien os la quita se quedará con la cara partida porque hace falta una clave para poder usarla... jejeje.



Preparación del Servidor para permitir autenticación por RSA

Accedemos a nuestro servidor:

ssh usuario@servidor.com

Tendremos que meter la clave como siempre.

Una vez dentro tendremos que editar el archivo /etc/ssh/sshd_config

sudo nano /etc/ssh/sshd_config

Buscamos las siguientes líneas y nos aseguramos de que estén así:
PubkeyAuthentication yes
AuthorizedKeysFile      %h/.ssh/authorized_keys

La primara opción permite el uso de clave pública para que un cliente se identifique.
La segunda especifíca donde se guarda la relación de claves públicas autorizadas.

Una vez modificado lo que sea necesario presionamos Ctrl+o para guardar, presionamos "enter" para confirmar y luego Ctrl+x para salir.

Comprobamos que existe la carpeta .ssh dentro del directorio home, el cual debe de contener el archivo authorized_keys

ls -al  ~

Si no existe lo crearemos

mkdir ~/.ssh
touch ~/.ssh/authorized_keys

En ese archivo se guardan las claves públicas de los clientes autorizados.

Necesitamos reiniciar el demonio ssh y normalmente eso no supone una caida del cliente que está conectado a ssh... así que:

sudo service ssh restart

Ahora ya podemos salir del ssh:

exit

Configuración del Cliente para usar RSA
El cliente de la versión actual de ssh está configurado para usar en primera instancia automáticamente una privada RSA para identificarse, así que solo tenemos que crearla.




Creación de parejas de claves

Ahora llega el momento de crear nuestra pareja de claves, es importante comprender que podemos crear la pareja de claves en cualquier pc y llevarlas a donde queramos.... pero en este caso las crearemos en el cliente.

Primero comprobamos que existe la carpeta .ssh dentro del directorio home, el cual es necesario ya que es ahí donde se generarán la pareja de claves.

ls -al  ~

Si no existe lo crearemos

mkdir ~/.ssh

Ahora generamos la pareja de claves RSA

ssh-keygen -t rsa

Nota: ssh-keygen genera por defecto claves RSA pero por si las moscas lo hemos especificado.

Creará una clave de 1028 Bits, muy segura, aunque se pueden crear mayores claves con menor rendimiento... claro está.

Tras ejecutar el comando nos preguntará donde generar la clave, le dejamos la ruta por defecto ~/.ssh/id_rsa

Seguidamente nos pedirá una clave de paso, yo uso la misma que para mi sesión, pero podéis usar cualquier clave que sea segura, que contenga numeros, símbolos y letras en minúscula y mayúscula.

Una vez terminado tendréis una clave privada (id_rsa) y otra pública (ud_rsa.pub) en el directorio .ssh de vuestra carpeta personal.

Ahora moveremos la llave pública al servidor usando scp, que pertenese al paquete de ssh y permite copiar contenido usando ssh de forma segura:

scp ~/.ssh/id_rsa.pub usuario@servidor.com:/tmp/

Y metemos la clave para mandar la llave pública a la carpeta temporal del server.


Añadiendo la clave pública al servidor ssh


Tras copiar la clave pública en el server hay que añadirlo al archivo authorized_keys

Accedemos al servidor ssh:

ssh usuario@servidor.com

Y ejecutamos:
cat /tmp/id_rsa.pub >> ~/.ssh/authorized_keys

Listo, ya podemos salir del server y al entrar no usaremos clave para iniciar sesión, y ojo, sigue leyendo.

exit

Usar ssh-agent para evitar la frase de paso

Si ya has intentado acceder pos ssh para probar la conexión te habrás percatado de que te pide contraseña.... ehhh! jeje para para, no me llames mentirosooooo jejee

Dije que no te pediría clave para iniciar sesión, y de hecho, no lo hace, lo que pasa es que tu clave privada está cifrada ¿Recuerdas que al crearla pusiste una clave para protegerla?

Usaremos ssh-agent, que se instala automáticamente al instalar ssh y que se ejecuta al inicio de cada sesión de manera automática.

Usaremos ssh-add para añadir la clave a ssh-agent de manera que esté vinculada a la sesión y no te pida más la pass para desencriptar la clave privada.... ya se encargará ssh de pedírsela a ssh-agent.

ssh-add ~/.ssh/id_rsa

Eso nos pedirá la frase de paso que usamos para crearla, y la añadirá a la base de datos.

Prueba ahora y verás...

Ya puedes usar tu clave privada sin temor, y compartir la pública para poder acceder a otros servidores o pc's sin tener que memorizar gran cantidad de claves.

Nota: Tras reiniciar o cerrar la sesión actual en tu sistema linux, se te volverá a pedir la clave de paso, pero puedes hacer que no te la vuelva a pedir pinchando en la opción "Desbloquear al iniciar sesión" .... o algo así XD

Bien, para terminar os recomiendo que impidáis el acceso mediante clave al server ssh.

¿Para qué?
Pues para evitar ataque de fuerza bruta y que intenten sacar el pass.

Accedemos a nuestro servidor:

ssh usuario@servidor.com

Ya no tendrémos que meter la clave como siempre, y se accederá por RSA automáticamente. XD

Una vez dentro tendremos que editar nuevamente el archivo /etc/ssh/sshd_config

sudo nano /etc/ssh/sshd_config

Buscamos las siguientes líneas y nos aseguramos de que estén así:
#PasswordAuthentication yes

Y la dejamos así:

PasswordAuthentication no 

Ahora reinicias el servicio ssh
 
sudo service ssh restartListo, ya no os pedirá contraseña normal y exigirá identificación por RSA.
Un saludo y espero que os sirva.