Viene de este otro artículo anterior, a raíz de la necesidad de ejecutar aplicaciones remotas en el servidor X local usando X11-Forwarding sin que se nos pregunte una contraseña. (Ideal para el acceso directo de la dama o el alias de bash del caballero).

Normalmente, si necesitamos conectarnos a un servidor SSH habitualmente, tendríamos que especificar el nombre de usuario y una contraseña. (Se especifica el usuario únicamente si nos autenticaremos remotamente como un usuario distinto al usuario que localmente ejecutará ssh)

Al cabo de un tiempo esto termina volviéndose tedioso por lo que usar un juego de llaves (key authentication) es la mejor solución.

Por otro lado, desde el punto de vista de la seguridad, –además de correr sshd en un puerto no privilegiado (de 1024 en adelante) y el buen fail2ban controlando los logs- la autenticación por llaves es muchísimo mas confiable en la medida en que nuestra clave privada se mantenga así (privada) y no caiga en manos de nadie.

Habiendo generado nuestro par de llaves RSA para autenticación ssh, una llave privada, y una pública, basta con copiar nuestra llave pública a todo servidor o pc contra la cual nos autenticaremos para que nos deje entrar sin preguntar quien está en la otra punta ni cual es la contraseña.

Sea cual sea el motivo que te lleve a implementar autenticación por llaves, por comodidad o por seguridad, veamos como se pone en funcionamiento:

Generar el par de llaves:

El comando ssh-keygen, que viene de serie con el paquete openssh es el encargado de generar nuestro juego de llaves:

~ $ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/mn/.ssh/id_rsa):
Created directory ‘/home/mn/.ssh’.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/mn/.ssh/id_rsa.
Your public key has been saved in /home/mn/.ssh/id_rsa.pub.

Dejando la contraseña (passphrase) en blanco durante el proceso, he generado mis dos llaves, la pública: id_rsa.pub dentro del directorio /home/mn/.ssh/  y la privada: id_rsa dentro del mismo directorio.

Copiar la llave pública a la ubicación remota:

Usando secure copy movemos nuestra clave pública hasta el servidor que frecuentamos:

~ $ scp ~/.ssh/id_rsa.pub usuario@servidor:

Instalar la llave pública en la ubicación remota:

Nos logueamos en el servidor (que todavía nos preguntará la contraseña):

~ $ ssh usuario@servidor

Password: **********
Last login: Wed Jul 29 23:19:44 ART 2009 from 5.192.233.114 on ssh

Y copiamos el contenido de nuestra llave pública dentro del archivo authorized_keys en el directorio  ~/.ssh/:

~ $ cat id_rsa.pub >> ~/.ssh/authorized_keys

~ $ exit

¡Y eso es todo!

Si nuevamente intento loguearme usando SSH en este servidor, ya no pregunta mi contraseña. Mi llave privada se coteja contra la llave pública y me permite el acceso de forma cómoda e instantanea:

~ $ ssh usuario@servidor
Last login: Wed Jul 29 23:20:09 ART 2009 from 5.192.233.114 on pts/0
servidor ~ $

Es importantísimo tener en cuenta que este método planteado, si bien es mucho mas seguro que el método tradicional de autenticación –que es vulnerable a ataques de fuerza bruta– a la vez representa un gran riesgo para la seguridad si alguien se hace con nuestra llave privada.

Quien tenga acceso local a la pc que almacena la llave privada automáticamente tiene acceso remoto a las pc o servidores que conocen nuestra llave pública.

Existiendo la posibilidad de especificar un password en nuestra llave privada automáticamente el sistema se vuelve seguro ya que en el caso de que este password no esté en blanco:

  • El acceso SSH no es vulnerable a ataques de fuerza bruta.
  • Nuestra clave privada no se puede desencriptar sin conocer el password.
  • Se nos pide el password de la clave privada en lugar de el password de usuario para iniciar sesión.

En este último caso se pierde la comodidad de loguearnos sin contraseña. Se nos pregunta la contraseña pero de la llave y no del usuario en cuestión. Esto también se puede automatizar haciendo uso de ssh-agent, pero es tema para otro artículo, para no complicar demasiado las cosas.

Supongamos el caso mas típico:

  • Hay dos PC en la red, mi pc corre Linux, la de mi (mujer / novia / ¿amante? / hermano / padre / madre / amigo) corre windows.
  • Necesitamos urgentemente usar una aplicación instalada en la pc que corre linux pero no podemos por tal o cual motivo y la única pc disponible en la red tiene Windows instalado.

O este otro:

  • Estamos fuera de casa / lugar de trabajo.
  •  necesitamos urgentemente correr una aplicación cualquiera de una pc que corre linux y la única pc que hay a mano tiene windows. Via internet, podemos conectarnos al servidor SSH de la pc remota y usarlo para traer una aplicación remota hasta la pc local.

X11 Forwarding al rescate:

Como windows no tiene ninguna implementación parecida al servidor X de forma nativa, necesitamos de Xming que es justamente eso: Un servidor X para windows. Pueden descargarlo e instalarlo (con las opciones por defecto es suficiente) desde la página web oficial de Xming (pesa actualmente 2.4Mb).

Teniendo en ejecución Xming (Tiene un ícono con una X en el system tray, al lado del reloj de windows), solo queda ejecutar putty para conectarnos a la pc linux:

  1. Ejecutamos putty.
  2. Ingresamos el número de IP  –o nombre de host si hay un DNS de por medio– (y puerto si fuera necesario) de la pc que corre linux.
  3. Ponemos la tilde en donde dice «Enable X11 Forwarding» dentro de Connection / SSH / X11
  4. Iniciamos sesión con nuestro nombre de usuario y contraseña (o par de llaves, pero eso es tema para otro artículo que tengo a medias).
  5. Ejecutamos la aplicación en cuestión.

Ejemplo: Xcalc ejecutado en la pc remota desde una pc con WIndows: 

XCalc corriendo nativamente en Linux pero manejado desde una pc con windows.

XCalc corriendo nativamente en Linux pero manejado desde una pc con windows.

Para que esto funcione de mas está decir que en la otra punta tiene que haber un servidor SSH corriendo.

Este servidor SSH tiene que permitir X11 forwarding, lo cual se consigue descomentariando la siguiente línea en /etc/ssh/sshd_config:

X11Forwarding            yes

Sirve para cualquier aplicación, pueden ejecutar desde la simple xcalc del ejemplo hasta algo tan complejo como Amarok, pasando por Mozilla firefox, aMSN, etc, etc…

Obviamente, también funciona en el caso que dispongamos de dos PC corriendo linux, cosa que simplifica bastante el proceso. Basta con ejecutar:

ssh -X <número_de_ip> xcalc

Para traer xcalc desde la pc remota al monitor local.

Algunas aplicaciones no se llevan bien con la opción -X. Firefox, por ejemplo, solo funciona si en lugar de -X se usa -Y:

ssh -Y <número_de_ip> firefox

Si se pretende usar este sistema sobre una conexión que va por internet, puede que te interese comprimir el tráfico al vuelo para mejorar el desempeño de la aplicación:

ssh -YC <número_de_ip> firefox

¿Conclusión?

Putty y Xming, dos herramientas que no te pueden faltar en el pendrive.

El día 4 de octubre de 2009 se celebra el décimo «cumpleaños» oficial de la distribución.

Convertida desde hace unos 4 años que la probé por primera vez en mi distribución de linux favorita, no puedo mas que recomendarla. La optimización en los binarios resultantes es espectacular, siempre a la última en software y siempre –simil highlander– irrompible. No hay con que darle.

Se invita a los usuarios a un irc-party…

¿Y eso que es?

Si me esperan hasta el 22/10/2009 les cuento. No tengo idea.

Mas información en la página web oficial: www.gentoo.org

Otro título sugerido: Yo contra el correo basura – Round 2

Prólogo:

Me acaba de llegar otra de esas odiosas cadenas de email en donde se prometen diferentes resultados en función de la cantidad de gente a la que uno la reenvíe, partiendo de la base de que con 10 personas es suficiente para que la persona que amas te llame por teléfono y llegando a sugerir que el hecho de ganar la lotería está íntimamente ligado al funcionamiento del protocolo SMTP encapsulado sobre TCP/IP.

Para que tengan una idea de la efectividad de este tipo de campañas inciadas por SPAMMERS como medio para recabar direcciones de correo electrónico, basta con contar cuantas hay contenidas en un solo mensaje de este tipo.

He guardado este mensaje en formato texto plano en cualquier lugar del disco rígido para luego poder contar cuantas direcciones de email contiene (incluyendo la mía, que sigue viaje, metida en el medio de la cadena, hasta llegarle a alguien que gana dinero por hacer spam).

En windows, seguramente tendrán que descargar algún programa de nombre parecido a «Advanced email counter and organizer» probablemente versión trial o shareware que podrán crackear bajando el respectivo crack de astalavista.box.sk o similares, esquivando previamente el virus camuflado contenido en el .zip.

Una vez crackeado, deberán ejecutarlo, ir a file / open / from archive o algo parecido y hacer uno o dos clicks mas, siempre y cuando sepan inglés.

En linux:

~ $ grep @ FW\:\ METAFISICA\ PURA…\ EL\ PODER\ DE\ LA\ ATRACCION.eml | wc
297 1010 21327

En una sola cadena de email, 1010 direcciones de correo electrónico diferentes.

¡Usen CCO, corten las cadenas de mensajes carajo!

Por si no se hubiera entendido como funciona mi invento contador de direcciones de email:

grep @ archivo.eml | wc

Simplemente filtrar con grep todas las líneas que tienen @ y pasárselas al WordCounter (wc) por medio de un | (pipe).