Vamos a ver si es posible aportar un poco claridad en este tema y en la lengua de Cervantes. Sí que es verdad que existe múltiple documentación en internet al respecto, pero yo al menos siempre he encontrado mejores las expIicaciones en la lengua de Shakespeare. Lo que quiero de este artículo es que sea breve, claro y útil.

tunel400

Vamos con el esquema:

  • SSH conceptos y aplicaciones necesarias para hacerlo funcionar.
  • ¿Por qué tunelar significa hacer segura una conexión?
  • Ejemplo con un cliente/servidor vnc.
  • Proxy a través de ssh.
  • La fonera y el firmware dd-wrt, ¿qué pinta aquí la fonera?

 

SSH conceptos y aplicaciones

Las siglas SSH, significan Securre Shell, identifican un servicio de conexión remota que se encripta utilizando algorítmos con claves asimétricas: una pública para encriptar que cada lado transmite al contrario y cualquiera podría interceptar y una privada para desencriptar, que cada lado mantiene en secreto para evitar que nadie ajeno pueda interpretar la comunicación. Para utilizar ssh, necesitamos un servidor que se encuentre a la espera de conexiones entrantes, normalmente en el puerto 22 y ubicado en una localización remota a la nuestra y un cliente que pueda utilizar ese servicio en la máquina en la que nos encontramos.

Bajo Windows, conozco 2 formas de configurar un servidor ssh. La primera consiste en instalar el entorno cygwin y dentro de éste el sshd (ssh daemon), que aparecerá como una opción más entre las múltiples que trae el menú gráfico de instalación. No obstante si no queremos un entorno completo de linux, sino solamente un servicio ssh, es más conveniente instalar open ssh.

En cuanto al cliente tenemos también conozco dos opciones: putty ya sea en Windows o en Linux (bajo Wine) o directamente el comando ssh bajo Linux. Putty es un secillo ejecutable que ocupa menos de medio megabyte y no requiere instalación. Bajo Linux el comando ssh estará directamente disponible.

 

¿Por qué tunelar significa hacer segura una conexión?

Cuando hacemos uso de un servicio remoto no seguro (por ejemplo vnc para ver/manejar un interfaz gráfico, o ftp para acceder a ficheros), los bytes que son transmitidos en ambos sentidos pueden ser fácilmente interpretados por un observador, dado que pertenecen a un protocolo bien conocido y no añaden ninguna encriptación que dificulte su entendimiento.

Por otro lado si el servicio es seguro (https, ssh), sabemos que ya saliendo de nuestro equipo todo viaja encriptado, por lo que el observador externo lo tiene más complicado para interpretar la información. Pues si con ssh la información viaja segura, ¿por qué no hacer que las conexiones de servicios no seguros viajen sobre una conexión previamente realizada de ssh? Es es justo lo que se hace al tunelar. Desde luego necesitamos un cliente ssh en nuestra ubicación (fácil de conseguir) y un servidor ssh en la remota (lo podremos instalar si el equipo nos pertenece).

Funcionamiento paso a paso:

Los clientes ssh permiten abrir en la máquina local (en la que estamos) puertos que son direccionados a su vez a puertos en la ubicación remota. Realmente lo que se hace es hacer una correspondencia directa entre el servicio remoto (en un puerto de la máquina remota) y un puerto abierto en la máquina local, de tal forma que la información que entregamos a nuestra máquina local en ese nuevo puerto, es llevada encriptada a través de la conexión ssh, desencriptada en el destino y entregada como si hiciéramos la conexión directa al puerto del servicio remoto. Como se ve, nosotros debemos conectar contra nuestro propio equipo (en el nuevo puerto abierto), es decir generalmente contra 127.0.0.1.

ssh

  1. Se establece la conexión ssh, desde el Host A al Host B, se abren puertos en el Host A para el reenvío encritptado de información.
  2. Los clientes conectan contra 127.0.0.1 (El propio Host A) en los nuevos puertos abiertos para el reenvío encriptado.
  3. Los datos se encriptan y se llevan a través de la conexión ssh (por el túnel representado en la parte superior) hasta el servidor ssh Host B. Una vez allí se desencriptan y se llevan al destino, Host C en el que se ubican los servicios requeridos.
  4. Los servicios ubicados en Host C reciben finalmente los datos

Ojito al pedazo de dibujo tipo paint que me gasto, ¿¿einn!!. Está hecho con kolourpaint, un paquete descarcable desde cualquier ubuntu. Se representa el caso más completo, en el que el servicio ssh está ubicado en un host distinto que el resto de servicios, aunque realmente todos los servicios podían estar en un mismo host remoto, pudiendo prescindir del host C.

 

Ejemplo con cliente/servidor VNC

Tenemos en sitioremoto.dyndns.org nuestro router, en cuya red local se encuentra el Host B. Dicho host tiene la IP (interna, en su red local) 192.168.1.2 y el Host C se encuentra en 192.168.1.3 (en la misma red local que B). Configuración típica de cualquier red doméstica o de pequeña empresa, en el que el router es 192.168.1.1 (esto último no viene a cuento, pero bueno, por centrar un poco) y tenemos un par de equipos en red. El Host B tendrá un servidor se SSH instalado (OpenSSH si tenemos Windows puede ser lo más fácil, en linux el servicio de ssh suele estar funcionando, consulta la documentación de tu distribución) y el Host C un servidor VNC (recomiendo tightvnc, funciona incluso cuando el escritorio dispone con múltiples monitores, enseñando todos en la conexión remota). Basta que en esta ubicación remota hayamos abierto el puerto del ssh (22) para el host B.

Apertura del túnel ssh

Si lo hacemos con el comando ssh de cualquier linux sería algo así:

ssh -l usuario -p 22654 -L 5901:192.168.1.3:5900 sitioremoto.dyndns.org

La opción -l especifica el usuario, -p el puerto y -L indica que vamos a abrir un puerto local (5901 en este caso) tunelado (a 192.168.1.3 y puerto 5900 en este caso).

Si tenemos putty, debemos introducir el nombre del sitio remoto y su puerto. Es recomendable abrir puertos que no sean los "bien conocidos", por ello asigno en el router el puerto externo 22654 (por ejemplo) al 22 de 192.168.1.2.

conecta

Antes de pulsar "Open" nos vamos a "Connection - SSH - Tunnels. Creamos un túnel desde el puerto local 5901 (local de nuestro equipo delante del que estamos sentados haciendo esto) al sitio remoto 192.168.1.3 (el que tiene el servidor de VNC) y puerto 5900 (el clásico de VNC).

tunela1

Pulsamos "Add" y queda como sigue

tunela2

Y ahora ya podemos pulsar "Open".

Nos pedirá que confirmemos la conexión y aparecerá la "huella" ssh del servidor. Este paso es fundamental para garantizar la seguridad. Deberíamos conocer la secuencia de la huella para estar seguros de que estamos conectando al nuestro servicio ssh, dado que en caso contrario podríamos estar conectando a un servidor ajeno a nosotros y tras esto meterle nuestro usuario y contraseña. ¿Que debemos responder?Pues depende del caso:

  1. Si la huella SSH es la esperada debemos responder siempre "NO". Si respondiéramos SI, se guardaría en el registro esta huella SSH y en el futuro no nos preguntaría. El registro es algo relativamente fácil de ser accedido, alguien con malas intenciones podría copiar nuestra huella y tratar de reproducir un servicio ssh alternativo al nuestro y con la misma huella.
  2. Si la huella SSH no es la esperada debemos pulsar "CANCEL"

Conexión del cliente VNC por el túnel

Basta que conectemos al puerto que acabamos de abrir en local (el 5901) y ya estaremos viendo nuestra pantalla remota:

vnc

 

Proxy a través de SSH

Los pasos son los mismos salvo lo referente al túnel; en este caso vamos a redireccionar tráfico web desde el equipo en el que estamos hasta el servidor SSH. La idea es que las peticiones web sean resueltas desde un lugar seguro y transferidas de forma encriptada hasta el equipo en el que estamos en la red no segura. De esta forma complicamos que desde nuestro trabajo o desde una red pública se pueda monitorizar nuestra navegación.

En el apartado de túneles debemos indicar que abrimos un puerto con direccionamiento dinámico, el reenvío se hace hasta el host con servidor ssh y es éste el que una vez allí "dinámicamente" decide a quién reenviar estas peticiones (al servidor web para el que vayan). Basta indicar el puerto como aparece en estas dos pantallas:

dynamic1

Pulsamos "Add" y queda como sigue:

dynamic2

Ya podemos pulsar open.

Si lo hubiéramos hecho con el comando ssh, se explica mucho más fácil:

ssh -l usuario -p 22654 -D 3000 sitioremoto.dyndns.org

Indicar en este momento que es posible abrir varios puertos y por lo tanto tunelar varios servicios sobre la misma conexión, sin más que añadir tantas especificaciones de puertos como queramos.

Una vez hecho esto vamos al navegador. Lo voy a poner para firefox pues tiene una opción interesante que permite tunelar también las peticiones DNS, si no se hiciera así, cualquiera en la red no segura podría ver los nombres de los sitios que visitamos, aunque no los contenidos que descargamos.

Nos vamos a las opciones del navegador - Avanzado - pestaña red - botón configuración y lo dejamos como sigue:

firefox1

Acto seguido en la dirección de destino del navegador ponemos "about:config" (sin comillas), filtramos por "Proxy" y activamos (con doble clic) el parámetro de firefox network.proxy.socks_remote_dns

Ya estaríamos navegando desde el servidor ssh remoto. Se agradecen los feedbacks.