lunes, agosto 15, 2005

Flash sin texto

Es posible que tras instalar el plugin de Macromedia Flash en algún navegador web de Linux (como Firefox o Konqueror) se tengan problemas a la hora de visualizar ciertos textos de las animaciones Flash. La animación se ve correctamente pero ciertos textos en vez de mostarse quedan sin dibujarse.
Esto se debe a que faltan los paquetes gsfonts-x11 y gsfonts, así que la solución es bien fácil:
apt-get install gsfonts-x11 gsfonts
Listo, tras reiniciar el navegador deberían verse correctamente los textos que daban problemas.

Sacado de #debian-es de los servidores irc de Debian (que son los de Freenode).

Preservando los datos EXIF

Gimp es un excelente programa de manejo de imágenes, pero parece que el soporte para datos EXIF no está muy avanzado, al menos en Debian Sarge/Stable.

Los datos EXIF (Exchangeable Image File) son usados por las cámaras digitales para guardar información extra sobre la fotografía que toman como la velocidad de obturación, apertura del diafragma o fecha y hora en que fue tomada la foto. Estos datos añaden a la información de la fotografia en el mismo archivo de la imagen.

Sin embargo, no todos los programas de edición conservan esos datos. Algunas vrsiones de Gimp, como por ejemplo la mía, al guardar la imagen elimina dichos datos.

Para conservarlos se puede usar jhead, programa de consola para manipualr datos EXIF.

Sólo es necesario meter todas las fotos en un directorio, por ejemplo ~/editando y copiarlas a un subdirectorio que se llame, por ejemplo, originales (~/editando/originales). Después se editan normalmente las fotos del directorio ~/editando, sin cambiar el nombre. Una vez finalizada la edición se ejecuta en el directorio ~/editando el comando:
$ jhead -te originales/"&i" *.jpg
Dicho comando transplanta los datos EXIF de las fotos del directorio originales a las fotos del directorio superior (dónde se ha ejectuado el comando), recuperando las fotos modificadas sus datos EXIF. Es importante no cambiar los nombres de las fotos uesto que el comando transplanta la información en función del nombre, si el nombre cambía la operación fallará.

sábado, agosto 13, 2005

SSH y autentificación mediante clave pública/privada

Para dar un poco más de seguridad y comodidad al acceso por SSH a mis servidores, he decidido utilizar autentificación mediante clave pública/privada junto a SSH.

El esquema es el siguiente: un servidor SSH posee una lista de claves públicas cada una asociada a un usuario. Cuando uno de dichos usuarios trata de conectarse al servidor SSH, el servidor comprueba que efectivamente el cliente es quién dice ser mediante un algoritmo de clave privada/pública, de manera que solo el cliente legítimo que posea la correspndiente clave privada podrá autentificarse.

Así, para ponerlo en marcha es necesario generar un par de claves (privada y pública) en el cliente, y enviar la clave pública al servidor.

Por otro lado el cliente almacena la clave pública del servidor, de manera que cuando el cliente se conecta al servidor puede comprobar que el servidor es efectivamente quién dice ser.

A ello:

La generación de la pareja de claves en el cliente se realiza mediante ssh-keygen:
$ ssh-keygen  -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/NaSz/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/NaSz/.ssh/id_rsa.
Your public key has been saved in /home/NaSz/.ssh/id_rsa.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx NaSz@quijote
Es posible proteger el uso de las claves mediante una clave, de manear que cuando se vayan a usar ésta sea solicitada. Si se deja en blanco no se pide contraseña.

Las claves se alamcenan por defecto en ~/.ssh/, quedando el directorio así:
$ ls -l
total 12
-rw------- 1 NaSz NaSz 883 2005-08-13 14:16 id_rsa
-rw-r--r-- 1 NaSz NaSz 223 2005-08-13 14:16 id_rsa.pub
-rw-r--r-- 1 NaSz NaSz 1344 2005-08-04 02:14 known_hosts
id_rsa es la clave privada, id_rsa.pub es la clave pública, y known_hosts son las claves públicas de los servidores conocidos.

Ahora se debe copiar la clave pública al servidor, al fichero ~/.ssh/authorized_keys. Para ello se utiliza el comando ssh-copy-id:
$ssh-copy-id -i ~/.ssh/id_rsa.pub NaSz@igor
$ssh-copy-id -i ~/.ssh/id_rsa.pub NaSz@sancho
ssh-copy-id es un script que se conecta al servidor ssh indicado mediante ssh, hace login y copia el archivo indicado por la opción -i en el fichero ~/.ssh/authorized_keys, además de tocar los permisos para dar seguridad (como impedir el acceso a miembros del grupo).

La primera vez que tratemos de conectar al servidor mediante ssh se nos pedira que confirmemos la clave pública del mismo (como hemos dicho, el cliente guarda también una copia de la clave pública del servidor para comprobar que efectivamente es el servidor que el cliente busca), de manera que ésta queda guardada, normalmente, en ~/.ssh/known_hosts.

Notas:

  • Se trabaja con usuarios y servidores. Es decir, para el servidor SSH un cliente es un usuario de una maquina concreta, por lo que para el servidor igor no será lo mismo NaSz@sancho que NaSz@quijote.

  • Ademas de claves RSA, se pueden usar claves DSA. Ámbas son válidas para usarse con ssh versión 2 (no es recomendavle usar ssh versión 1 dado que es vulnerable).

  • Existe la posibilidad de usar ssh-agent que se encarga de gestionar el uso de las claves. Mediante ssh-agent y si se ha usado una clave para proteger el uso de las claves privadas (ver explicación de como generar las claves), el usuario sólo tiene que introducir la clave o palabra de paso una vez. ssh-agent se encarga de permitirle el uso de las claves privadas la próxima que lo necesite sin tener que volver a introducir la contraseña. Es útil para dar un toque mayor de seguridad sin la incomodidad de tener que usar una contraseña cada vez que se quiere conectar a un servidor conocido mediante SSH.

  • Notar que este sistema permite el acceso sin contraseña en todos los servidores que confien en el sistema del cliente, de manera que por un lado introduce seguridad, pero si un sistema se ve comprometido también se podrán ver comprometidos aquellos servidores que confien en el sistema atacado. Por ello es un mecanismo a usar con inteligencia y moderación.


La mayor parte de ésta información ha sido sacada del Blog de Laura Cedrán (aparte de éste artículo hayun par más que profundizan en SSH), del artículo "ssh sustituye a rsh" (desconozco el autor), así como del artículo de Bulma "SSH con contraseña pública/privada".