En Internet existen varios sitios similares a Youtube donde mucha gente ha subido videos. Blinkx es un lugar donde se hace referencia a programas completos de series de televisión. La analogía que ellos usan es la de un control remoto donde se puede escoger que ver y su eslogan es “pon celosa a tu televisión”. La verdad es que ese eslogan lo dice todo.

Una vez dentro de Blinkx buscamos nuestra serie favorita y nos presentará una ventana con todas las temporadas ordenadas desde la más nueva a la más vieje. Seleccionamos el capítulo a ver y luego debemos seleccionar en donde queremos ver. Normalmente prefiero utilizar los de Megavideo aunque los de VideoBB suelen tener mejor calidad. Existen otros y no nos queda más que probar.

Las principales ventajas de ver televisión por Internet es que podemos ver los programas de televisión que queremos ver a la hora que queramos.

Espero disfruten de Blinkx.

Una Red Privada Virtual (VPN por sus siglas en inglés) sirve para crear una conexión encriptada entre 2 o más puntos a través de Internet. Un caso de uso típico puede ser permitir al acceso a servicios de una intranet de forma segura desde Internet.  Otro caso típico de uso es interconectar redes locales de 2 ó más sucrusales a través de Internet. En este artículo haremos la primera opción y en un futuro cercano publicaré cómo interconectar 2 redes.

Existen varias implementaciones de VPN y en el mundo de software libre una de las más populares es OpenVPN.  Una de sus grandes ventajas, es que se pueden tener clientes en distintos sistemas operativos com GNU/Linux, Windows, Mac y seguro que en todas las versiones BSD.

Instalación

OpenVPN viene por defecto en la mayoría de las distribuciones GNU/Linux. En mi caso suelo utilizar Debian o Ubuntu. La instalación la hice con aptitude:

aptitude install openvpn

En distros basadas en RPM la instalación se la hace con yum:

yum install openvpn

Listo , así de fácil y de sencillo.

Crear los certificados digitales

OpenVPN autentica sus clientes a través de llaves públicas y privadas. De esta manera cada cliente tiene su llave privada y debe enviar su llave pública al servidor. Estas llaves son creadas con un certificado conocido como “Certificado de Autoridad“. De esta forma cuando el servidor recibe una llave pública este revisa si esta firmado con el certificado de autoridad. Sino esta no aceptará la conexión.

La forma más fácil de crear estos certificados es utilizando la utilidad easy-rsa que viene en el paquete de OpenVPN. En el caso de debian esta aplicación se encuentra en: /usr/share/doc/openvpn/examples/easy-rsa/2.0/ easy-rsa. Otras distribuciones tendrán una ruta similar.

Copiamos la aplicación a una ruta más fácil de recordar. Personalmente opté por un subdirectorio dentro de /etc/openvpn. Para tener las cosas ordenadas:

cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0/ /etc/openvpn/easy-rsa


Ahora ingresamos al directorio para crear las claves:

cd /etc/openvpn/easy-rsa/

Dentro de esta carpeta tenemos un archivo que almacena algunas variables importantes. Recomiendo revisar este archivo y de ser el caso modificar algunas variables.

vim vars

En mi caso personalice la siguiente parte para que cuando cree los certificados los valores por defecto tengan que ver con mi realidad:

export KEY_COUNTRY="EC"
export KEY_PROVINCE="Pichicha"
export KEY_CITY="Cayambe"
export KEY_ORG="Mi empresa"
export KEY_EMAIL="yo@midominio.com"

Guardamos y cerramos el archivo. Si no queremos no modificamos el archivo, es algo netamente opcional.

Cargamos las variables de este archivo al shell que estamos utilizando:

. vars

Borramos las claves previamete creados en caso de existir. Hacer esto solo si es la primera vez que vamos a crear los certificados y las claves.

./clean-all

Creamos el certificado de autoridad:

./build-ca

Si modificaron las variables, se darán cuenta que ahora las estaremos utilizando.

Certificado y clave privada para el servidor

/build-key-server servidor

Esto generara los archivos servidor.crt y servidor.key. donde el archivo .key es la llave privada y .crt es la pública.

Generamos los parámetros  Diffie Helman

./build-dh

Generamos las claves de los clientes.

./build-key cliente1
./build-key cliente2
./build-key cliente3


De manera similar al servidor se crearán las claves *.key y *.crt que serán las claves privadas y públicas respectivamente. Las 2 claves las deberemos copiar al cliente.

Listo, hemos creado todos los certificados necesarios y estamos listos para configurar los clientes y el servidor. Es importante sacar un respaldo del directorio /etc/openvpn/easy-rsa ya que ahí están todas las claves, incluido el certificado de autoridad que nos permitirá crear nuevas claves a futuro.

Resumen de las claves y certificados creados:

Nota: en clienteX, X quiere decir el número del cliente. En este ejemplo estamos trabajamos con 3 clientes para la VPN pr lo que deberíámos tener 3 pares de claves .crt y .key.

Configurar el Servidor

Copiamos los archivos que corresponden al servidor en una carpeta dentro del mismo. En mi caso copie la configuración en /etc/openvpn/claves. Si generamos las claves en una máquina que no es el servidor debemos usar scp u otra aplicación para subirlas a nuestro servidor.
Copiamos un archivo de ejemplo de configuración del servidor y la adaptamos a nuestras necesidades.

cd /etc/openvpn
cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz .
gunzip server.conf.gz
vim server.conf


Dentro del archivo modificamos algunas variables para que funcione. Aquí expico algunas:
Protocolo a utilizar:

# TCP or UDP server?
proto udp


Vamos a configurar la vpn utilizando el protocolo UDP ya que esto nos dará un mejor rendimiento. No tiene sentido trabajar en TCP ya que dentro de nuestra vpn se correra el protocolo IP donde de ser necesario se volver a utilizar el protocolo TCP y no tiene sentido utilizar 2 veces este protocolo. En otras palabras, utilizar TCP solo cuando no lo puedan hacer con UDP.

Definimos las rutas a los certifiados. Recordar que en este ejemplo estamos utilizando /etc/openvpn/claves

ca claves/ca.crt
cert claves/servidor.crt
key claves/servidor.key
dh dh1024.pem


Por último, en el mismo archivo, decimos a que redes queremos que los clientes vpn puedan acceder.

push "route 192.168.45.0 255.255.255.0"

Listo podremos iniciar el servidor:

/etc/init.d/openvpn start

En caso de necesitar corregir errores se puede iniciar el servicio así:

openvpn <archivo de configuración>

Nota: El servidor VPN debería poder trabajar como ruteador por lo que debemos activar esto a nivel del kernel:

echo 1 > /proc/sys/net/ipv4/ip_forward

Para que la configuración quede grabada y no se pierda al reiniciar la máquina se debe editar el archivo /etc/sysctl.conf y poner el valor de 1 a la variable correspondiente:

net.ipv4.ip_forward=1

Configuración de un Cliente

Instalar OpenVPN en el cliente. En el caso de usar Linux, la instalación es igual a como se instala el servidor.
Copiamos los archivos correspondientes al cliente dentro de la máquina del mismo (Ver la tabla de arriba). En mi caso los copie en /etc/openvpn/claves

Una vez que tenemos las claves, copiamos un archivo de configuración de ejemplo para cliente y lo configuramos para nuestras necesidades:

cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn/
vim client.conf

Definimos el protocolo como UDP igual que en el servidor:

proto udp


De manera similar al servidor, editamos las varialbes ca, cr y key:

ca claves/ca.crt
cert claves/clienteX.crt
key claves/clientX.key

El cliente debe saber a que servidor se debe conectar. Para esto debemos utilizar un nombre de dominio o el IP público y el puerto a conectarse. Por defecto OpeVPN corre en el puerto 1194.

remote miservidor.com 1194

Iniciamos OpenVPN en el cliente

/etc/init.d/openvpn start

En caso de tener errores podemos probar con

openvpn <archivo de configuracion>

Para probar la conectividad podemos hacer ping al ip 10.8.0.1 que es el ip de nuestro servidor. Si lo hacemos ya estamos con la VPN arriba. en caso de haber puesto la sentencia push podríamos hacer ping a ips dentro de la red LAN donde se encuentra la VPN. Ojo que las máquinas de la red LAN deberían saber como llegar a la red 10.8.0.0/24, para esto deberíamos ver la configuración del servidor.

Referencias Adicionales

• How to OpenVPN

1. SSH con Llaves Públicas y Privadas: Autentificar un usuario con contraseñas tiene sus problemas. Si administramos varios servidores debemos recordar la clave de todos y muchas veces para no olvidaras utilizamos claves débiles. Al utilizar llaves públicas y privadas solucionamos estos 2 problemas.
2. Túneles SSH (parte 1): Es muy probable que alguna vez sea necesario ingresar a un servidor dentro de una Intranet con IP privada desde Internet. Si tenemos un servidor con acceso a SSH accesible desde Internet y que puede ver esta IP privada, asunto solucionado con túnles SSH
3. Túneles SSH (parte 2): En este how to se aprende como compartir servicios desde mi máquina con IP privada hacia Internet gracias a los túneles SSH. El ejemplo más interesante es como con un servidor SSH en un ip pública, 2 máquinas con IPs privadas en distintas redes se pueden ver entre sí sin necesidad de VPNs.
4. Aplicaciones Gráficas en Red con SSH: Todos usamos SSH para acceder a línea de comandos en un servidor. No todos saben que también podemos usar SSH para acceder a aplicaciones gráfica en nuestra red.
5. SSH y Proxy Socks navegación segura en Internet: Con una simple opción de SSH podemos navegar en Internet de forma encriptada y sin restricciones. Muy útil cuando navegamos en sitios done los servidores proxy no dejan navegar a ningún lugar o donde queremos tener mayor seguridad al navegar.
6. SSH y HTTPS en el puerto 443: Muchas veces el puerto 22 puede estar bloqueado en una red, haciendo que la mayoría de estos tips no sean útiles. Sin embargo, muy rara vez una red bloqueaa el puerto 443, en este ejemplo se enseña como hacer para compartir el puerto 443 para HTTPS y SSH de manera simultanea.
7. Copia Remota con SCP: La herramienta SCP permite copiar archivos a través de la red utilizando el protocolo SSH. En este tip aprenderemos como hacer esto y además como hacerlo limitando el ancho de banda si queremos copiar archivos muy grandes.
8. Simplifica tu vida gracias a  ~/.ssh/config: Manejamos varios servidores, cada uno de ellos utiliza puertos diferentes. Podemos configurar nuestro cliente SSH para que algo como “ssh -p 2200 usuariox@servidorremoto.com” sea tan simple como “ssh serv“
9. SSH y SFTP con usuarios enjaulados: Muchas veces se tiene la necesidad de dar acceso a nuestro servidor a personas en las que no confiamos. En este tip se aprende como hacer para crear un ambiente limitado para estos usuarios y que tengan solamente las herramientas que necesitan.
10. Sincronizar Directorios con SSH y RSYNC: RSYNC, es una poderosa herramienta de sincronización a través de la red. En este tip se aprende como combinar su poder con SSH y poder sacar respaldos o crear mirrors de forma segura.
11. Proteger SSH con Fail2Ban: Muchas personas creen que cambiar el puerto de SSH significa asegurar su servidor. Cualquier persona que conoce poco de nmap y sabe usar Google seguro podrá descubrir en que puerto se ejecuta SSH. Fail2Ban es una herramienta mucho más poderosa que bloquea los IPs luego de X números de intentos fallido por un tiempo Y. De esta manera se hacen inútiles los ataques de diccionario.

Instalar Fail2Ban

En las distros basadas en Debian, basta con instalar el paquete fail2ban. Supongo que en otras distros la instalación es igual de simple

aptitude install fail2ban


Configurar Fail2Ban

Como cualquier aplicación de Linux, su configuración se encuentra dentro del directorio /etc. En este caso el directorio donde debemos buscar es /etc/fail2ban. El archivo que modicaremos en este mini tutorial es el /etc/fail2ban/jail.conf. Por defecto viene con varios templates para proteger servicios de nuestros servidores, no solo SSH. Algunas variables interesantes para modificar:
Al inicio del archivo encontraremos las variables ignoreip y bantime La primera sirve para que no bloquee mi IP si algo sale mal y la segunda especifica el tiempo a bloquear un IP en segundos. Por defecto son 10 minutos (600 segundos).

ignoreip = 192.168.182.3
bantime = 600


Luego bajamos a la sección de SSH y verificamos que la configuración este correcta:

[ssh]

enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 6


Reiniciamos fail2ban

/etc/init.d/fail2ban restart


Listo ahora estamos protegidos contra los ataques de diccionario a nuestro servidor SSH

Si bien RSYNC no necesita de SSH para sincronizar, utilizar los 2 en conjunto tiene algunas ventajas entre las que destaco algunas:

• La información viaja encriptada
• No necesito correr un servidor RSYNC
• Solo necesito preocuparme de tener abierto el puerto de SSH

Nota: todos los ejemplos son una sola línea

Ejemplo 1: Sincronizar 2 servidores web

rsync -avz --delete  -e ssh /var/www/sitioweb usuario@servidorremoto.com:/var/www/mirror

Las opciones quieren decir:

• -a Sirve para hacer una sincronización recursiva
• -v Sirve para mostrar en pantalla información de lo que esta haciendo el proceso
• -z Sirve para enviar la información comprimida y ahorrrar ancho de banda
• –delete Sirve para borrar del destino todo lo que no esta en el origen. En otras palabras para tener un mirror 100% igual.
• -e ssh: Es la parte del comando que hace que este artículo sea catalogado como un tip ssh . Básicamente sirve para hacer la sincronización utilizando el protocolo ssh

Al igual que SCP el primer directorio es el origen y el segundo es el destino.

Ejemplo 2: Sincronizar con puerto  no Estandard

Algo muy común es que la gente  corra el servidor SSH en un puerto distinto al 22. Inclusive hace unos días publiqué como hacer para que escuche en el puerto 443. Ahora explicamos como sincronizar los 2 directorios donde el puerto del destino no es estandard.

rsync -avz –delete –rsh=’ssh -p 443′ /var/www/sitioweb usuario@servidorremoto.com:/var/www/mirror

Como pueden ver hay un solo cambio en este ejemplo. En lugar de usar -e ssh utilizamos --rsh=’ssh -p 443′. Básicamente estamos diciendo que se utilice el puerto 443 en lugar del puerto 22.

Recomendaciones

Si desean hacer tareas automatizadas como usar su servidor como un mirror de un tercer (ej. Elastix, Wikileaks ) es muy recomendable crear un ambiente enjaulado para ese usuario SSH y seguro necesitará trabajar con autenticación con llaves públicas y privadas.

Nota: Todos los ejemplos que pongo a continuación con SSH se podría utilizar con cliente SFTP como Filezilla.

Descargar el script make_chroot_jail y guardarlo en /usr/local/sbin:

cd /usr/local/sbin
wget http://www.fuschlberger.net/programs/ssh-scp-sftp-chroot-jail/make_chroot_jail.sh
chmod 700 make_chroot_jail.sh


La razón por la que guardamos el archivo en /usr/local/sbin, es porque es una ruta estandard para poner aplicaciones o scripts que no vienen con la distribución que usamos y que deben ser ejecutadas solo por el administrador. Además tiene la ventaja de estar incluido en el path de los administradores por lo que se puede ejecutar directamente escribiendo make_chroot_jail.sh en lugar de la ruta completa.

Modificaciones al script

Antes de ejecutar el script, me encontré con algunos detalles que deben ser cambiados para que funcione perfectamente. El primer cambio que se debe hacer es cambiar la primera línea del archivo. En lugar de decir:

#!/bin/sh

Deberíá decir

#!/bin/bash

Normalmente el comado /bin/sh es un link a /bin/bash, pero esto no es cierto en todas las distros. Para que este script funcione correctamente deberíamos ejecutarlo con el shell bash.

En el caso de mis pruebas con Ubuntu 10.4 y Debian Squeeze es necesario modificar la línea 472 y cambiar la librería:

/lib/libcap.so.1

por

/lib/libcap.so.2

En este script Ubuntu es reconocido como Debian. Así que en los 2 casos hay que modificar la línea 472. Si estas usando una distro como Suse, Fedora u otra, habría que modificar la línea correspondiente.

Personalizar el Ambiente

La última modificación que debemos hacer al script es agregar o quitar (lo dudo) las aplicaciones que queremos darle al usuario. En el caso de Debian/Ubuntu deberíamos modifcar la línea 119.

Crear el primer usuario:
La forma más básica de crear el usuario es:

make_chroot_jail.sh gnu

En este caso creamos el usuario gnu que será un usuario enjaulado. Ahora intentemos ingresar al servidor y listemos algunos directorios para ver si todo esta en orden.

ssh gnu@servidorremoto.com
ls /

Si la salida del comando es la siguiente hemos creado exitosamente nuestra Jaula.

bin dev etc home lib sbin usr

Por defecto la jaula se creará en el directorio /home/jail. Este directorio se podría cambiar pasando argumentos al comando. Para ver lo que se puede hacer con este script podemos ejecutarlo de la siguiente forma

make_chroot_jail.sh | less


Si quisieramos podríamos crear varios usuarios dentro de la misma jaula.

Crear varias Jaulas ssh

Es muy probable que queramos tener varias usuarios y cada uno con su propio ambiente chroot. Esto es algo muy útil si alguien vende hosting y quiere que sus usuarios utilicen SFTP en lugar de FTP, aumentando mucho la seguridad para los usuarios y para el servidor. Para crear los usuarios en un ambiente distinto se les debe asignar un shell propio y un directorio donde estará la jaula.

Con un ejemplo se entiende mejor. Vamos crear 2 ambientes enjaulados. El primero tendrá su shell como /usr/local/bin/shelltuxs y su ambiente chroot estará en /jaulas/tuxs. El segundo tendrá su shell como /usr/local/bin/shellgnues y su ambiente chroot estará en /jaulas/gnues. Podríamos tener tantos ambientes enjaulados como quisieramos, pero cada uno deberá tener su propio shell. Los shells que estamos creando podríán estar en cualquier directorio y llamarse de cualquier forma. El script los creará.

Crear usuarios gnues y su ambiente

make_chroot_jail.sh gnu1 /usr/local/bin/shellgnues /jaulas/gnues/
make_chroot_jail.sh gnu2 /usr/local/bin/shellgnues /jaulas/gnues/
make_chroot_jail.sh gnu3 /usr/local/bin/shellgnues /jaulas/gnues/


Crear usuarios tux y su ambiente:

make_chroot_jail.sh tux1 /usr/local/bin/shelltuxs /jaulas/tuxs/
make_chroot_jail.sh tux2 /usr/local/bin/shelltuxs /jaulas/tuxs/
make_chroot_jail.sh tux3 /usr/local/bin/shelltuxs /jaulas/tuxs/

Listo hemos creado 2 ambientes enjaulados y cada ambiente enjaulado. La verdad esta mucho más fácil que hace algunos años atrás cuando hice esto por primera vez.

Algunas consideraciones.

Si bien este script nos facilita la vida, tiene algunas errores. Si se actualiza varias veces el mismo usuario, habría que revisar el archivo /etc/passwd tanto en el ambiente real como el enjaulado para que no tenga usuarios repetidos. Lo mismo se debería hacer con el comando visudo y borrar los usuarios repetidos.

Supongamos que debemos ingresar a un servidor remoto, con un nombre de usuario que no es el mismo de mi máquina local y además corremos el servidor en un puerto distinto al 22. Cada vez que accedamos a este servidor deberíamos escribir algo así:

ssh -p 443 usuarioremoto@servidorremoto.com

No es el fin del mundo, pero si tenemos muchos servers y una mala memoria se nos complica un poco la vida. Que tal si en lugar de escribir toda esa línea podemos escribir simplemente:

ssh sremoto

Gracias al archivo de configuración ~/.ssh/config  podemos hacer sin problema. Empezamos creando el archivo:

vim ~/.ssh/config

En mi caso estoy utilizando vim como editor, pero podría ser un editor gráfico como gedit. El caracter “~” quiere decir home del usuario con el que estoy trabajando en este momento. En otras palabras si estoy trabajando con el usuario juan entonces lo más probable es que “~” se refiera a /home/juan/.
En el archivo de configuración añadimos las siguientes líneas.


Host sremoto
HostName servidorremoto.com
User usuarioremoto
Port 443

La primera línea es algo así como un alias para este servidor. La segunda línea nos dice el nombre del host para el servidor. En la tercera ponemos el nombre de usuario y en la última el puerto. No existe un orden específico sobre las variables que podemos utilizar. Podemos tener tantos Host como sea necesario.

Listo ahora ingresamos al servidor remoto.

ssh sremoto

Inclusive se puede utilizar el alias “sremoto ” para copiar archivos con scp

scp archivo sremoto:

En este ejemplo estamos poniendo solo un servidor remoto, pero podríamos tener los que queramos. Las variables con configuramos aquí no son las únicas. Para más información sobre lo que podemos hacer con este archivo de configuración basta ver su página de manual:

man ssh_config

El comando SCP básicamente sirve para copiar archivos de un computador a otro, de manera encriptada, a través del protocolo SSH. Funciona de manera muy similar a como funciona el comando cp, donde tenemos un origen y un destino. La diferencia es que el origen o el destino van a ser computadores diferentes.

Ejemplo 1: Origen local, destino remoto

scp archivo.tar.gz usuario@servidorremoto.com:

En este caso el origen es un archivo local de la computadora donde estoy trabajando y el destino es el servidor remoto. El “:” al final del nombre del servidor quiere decir que vamos a copiar el archivo en el directorio home del usuario que realiza la copia. Después del : podríamos poner una ruta relativa al home del usuario o una ruta absoluta. Por ejemplo, si quisiera copiar en la ruta /home/usuario/directoriox

Rutas relativas:

scp arhivo.tar.gz usuario@servidorremoto.com:directoriox

Rutas absolutas:

scp arhivo.tar.gz usuario@servidorremoto.com:/home/usuario/directoriox

En este caso es más comodo usar la ruta relativa, pero no siempre será este el caso.

Ejemplo 2: Origen remoto, destino local

scp usuario@servidorremoto.com:arhivo.zip .

En este caso copiamos el archivo remoto archivo.zip (ubicado en el home del usuario) A la carpeta actual donde me encuentro en mi máquina local.
Tanto para el ejemplo 1, como para el 2 si quisieramos copiar un directorio, lo haríamos con la opción “-r”. En general las opciones de scp son las mismas que las del comando cp

Ejemplo 3: Puerto alternativo

Muchas personas no corren ssh en el puerto 22, en un post anterior expliqué como hacer para correr ssh en el puerto 443 en conjunto con https. Pues bien, ahora hagamos un ejemplo de copia de scp utilizando el puerto 443.

scp -P 443 -r /ruta/directorio usuario@servidorremoto.com:/ruta/deestino


En este caso copiamos todo un directorio y lo hacemos por el puerto no estadard 443.

Ejemplo 4: Limitar Ancho de Banda

Esta opción no la sabe mucha gente y en ocasiones puede ser muy útil. Que tal si queremos copiar un archivo muy grande desde o hacia Internet. Es muy probable que eso genere mucho tráfico que haga insoportable el uso del Internet para el resto de personas en la red, incluido quien esta subiendo el archivo. Por suerte, parece ser que los desarrolladores de Openssh han pensado en todo y se puede limitar el ancho de banda de la transeferencia. Para esto usamos la opción “-l” seguido por el ancho de banda a limitar en kbits/segundo. (8 kbit/segundo = 1 kbyte/segundo)

scp -l 80 archivgrande.tar.gz usuario@servidorremoto.com:

De esta manera limitaremos la copia a 80 kbits/seg (10 kbytes/segundo).

Una solución simple podría ser ejecutar SSH en el puerto 443, pero lo más probable es que necesitemos correr alguna aplicación HTTPS en ese puerto. La solución a este problema se llama SSLH. Sus autores lo llaman un multiplexor SSH/HTTPS.

Básicamente lo que hace este servicio es redirigir las peticiones de SSH a localhost:22 y las de HTTPS a localhost:443. Para que todo funcione bien debemos deberíamos configurar nuestro servidor web para que escuche en: 127.0.0.1:433 en lugar de *:443.

Manos a la Obra

Nota: Si se va hacer esto en un servidor remoto podría perder la conexión al mismo. Trabaje con atención y mantenga una conexión de ssh abierta por si las moscas.

Lo primero que tenemos que hacer es instalar SSLH. En las distribuciones basadas en Debian (ej. Ubuntu) bastará instalarlo desde repositorios. En otras distros supongo que el procedimiento debe ser muy similar.

aptitude install sslh

Una vez instalado, lo primero que debemos hacer es configurar nuestro servidor web para que el puerto 443 sea solo escuchado en localhost y no en el ip público.  En mi caso personal uso Cherokee y para esto en el Cherokee admin debemos ir a: General-> puertos. Una vez ahí añadimos la dirección ip junto a la directiva de 443.  En el caso de Apache o cualquier otro servidor web se aplica el mismo concepto.

El servicio ssh si queremos lo podemos configurar para que escuche solo en 127.0.0.1:22 ya que ahora podríamos acceder desde el 443. No recomiendo hacer esto hasta que todo este funcionando.

Una vez que tenemos configurado el servidor web, tenemos que configurar el sslh. Para esto editamos el archivo /etc/default/sslh. Básicamente se debe añadir la lista RUN=yes y configurar el ip pública de nuestro servidor. Deberíamos tener algo similar a esto:

DAEMON_OPTS="-u sslh -p 200.200.200.200:443 -s 127.0.0.1:22 -l 127.0.0.1:443 -P /var/run/sslh.pid"
RUN=yes

Nota: Son solo 2 líneas la primera define la variable DAEMON_OPTS y la segunda la variable RUN.

Ahora solo queda arrancar el servicio

/etc/init.d/sslh start

Listo ahora podemos ingresar a nuestro servidor utilizando el puerto 443

ssh -p 443 usuario@servidorremoto.com

Ahora si quisieramos navegar utilizando un proxy socks básicamente deberíamos hacer algo así:

ssh -p 443 -ND 8080 usuario@servidorremoto.com

Ahora ya estamos preparados para redes hostiles donde les gusta bloquear lo que más pueden.

Les recomiendo leer el siguiente artículo de Linux Magazine donde Charlie nos cuenta sobre sslh. Si no hubiera sido por Charlie, no supiera como hacer esto y no hubiera escrito este artículo. Sin lugar a dudas mi columna favorita de Linux Magazine.

ssh -X usuario@ipservidor thunderbird

Ahora que tal si queremos ejecutar más de una aplicación gráfica. Podríamos utilizar una sola sesión de ssh para abrir varias aplicaciones.

ssh -X usuario@ipservidor
thunderbird &
oowriter &
gnome-calculator&


En este caso no ponemos la aplicación a ejecutar al momento de hacer ssh, sino que las empezamos a ejecutar desde que ingresamos a la máquina remota. De esta manera podemos ejecutar una aplicación después de la otra añadiendo el carácter "&" al final de cada comando para que se ejecuten en segundo plano. De esta forma podemos ejecutar varios comandos en el mismo terminal.


Conclusión

Como se puede ver ejecutar aplicaciones gráficas en red puede ser muy útil si nos manejamos en pequeñas o grandes redes. Una de las utilidades que más me gusta es para reutilizar computadoras viejas. Se podría en una máquina de pocos recursos ejecutar aplicaciones gráficas a través de la red desde un computador con más recursos. Así podríamos ejecutar aplicaciones como openoffice en computadores de más de 10 años. Hace muchos años escribí un how to sobre el tema en el Ecualug. LTSP o TCOS son mejores soluciones para estos problemas.