Bajo la premisa: «No es que yo sea paranoico, es que me están siguiendo…» alguien ha creado un par de scripts que hacen a tu pc ridículamente segura y hasta le ha dado nombre (y apellido); Crypto Port Knocking 0 Single packet authentication. –o ambas cosas juntas, en realidad

Sencillamente genial.

¿Creíste que tu Linux con SELinux, ACL, Port knocking, Fail2ban, Snort, OSSEC, sin puertos abiertos, con autenticación SSH basada en llaves, con el usuario root deshabilitado y todos los servicios enjaulados, los DNS y la tabla ARP estática era seguro?

No… No es seguro. Al menos no para el creador de esta obra maestra de la seguridad que ha llevado la cosa a tal extremo que raya con el absurdo.

Si te interesan estos temas, después del salto viene lo bueno. Es fundamental tener una noción básica de bash y entender un poco de inglés para echarlo a andar:  Continúa leyendo

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.