Mostrando entradas con la etiqueta SSH. Mostrar todas las entradas
Mostrando entradas con la etiqueta SSH. Mostrar todas las entradas

Manual SSH: El dios de la administración remota

Y es que no se merece un titular peor. ¿Has estado alguna vez en el trabajo o en casa de y has necesitado o te has acordado de un archivo que no tienes en ese momento pero sí en tu ordenador? Existen los escritorios remotos, de hecho Ubuntu trae uno instalado por defecto, pero puede que no queramos hacer más que mandarnos un archivo o hacer algo en el ordenador remoto. Para esto -y mucho más- existe SSH, con un inmenso potencial.

SSH son las siglas de Secure SHell. Lo que te ofrece es una consola en un ordenador remoto con los privilegios que tenga la cuenta con la que conectes. Es decir, si en tu PC tienes varias cuentas, puedes conectar desde otro ordenador al tuyo con cualquiera de esas cuentas y sus respectivos privilegios, como pudiera ser la cuenta root, la de tu administrador sudo o la de un usuario normal sin poder de administración. Y todo esto con encriptación de datos.

En este tutorial os voy a mostrar algunas facetas de su uso, pero antes debéis saber que tener el servidor de SSH corriendo es de cierto riesgo, ya que si no tocáis la configuración por defecto para aumentar la seguridad a un nivel más que aceptable, puede ser un agujero para que alguien pueda entrar en vuestro sistema. Pero no os preocupéis, si seguís estos pasos es difícil que suceda, nunca imposible, pero sí difícil.

El manual es algo extenso debido a que he intentado hacer que resulte bastante completo y que, como llevo haciendo en el resto de tutoriales, quiero que sepáis lo que estáis haciendo, los porqués y lo que significa cada cambio que hacéis. De esta forma tendréis criterio propio para vuestras modificaciones personales.

Instalar

En vuestros repositorios ya tenéis SSH dispuesto a instalar, así pues:

$ sudo aptitude install ssh

Una vez instalado se autoiniciará el demonio que ejecuta el servidor SSH y gestiona las solicitudes de login remoto.

Configuración: Mayor seguridad

Como decía antes no es muy inteligente usar SSH sin modificar el fichero de configuración del servidor. Vamos a modificar algunas opciones para conseguir una seguridad aceptable.

$ sudo gedit /etc/ssh/sshd_config

(nota) Si algunas de las opciones que aquí comento no aparecen en vuestro sshd_config, simplemente agregadlas. Podéis hacerlo donde queráis, aunque lo suyo es que lo hagáis al principio o al final para que sepáis cuales son las opciones que vosotros habéis agregado.

Vemos un fichero de configuración típico basado en “opción valor”. Vamos a comenzar las modificaciones por el puerto que es lo primero que vemos y una de las cosas más importantes. SSH usa por defecto el puerto 22. Esto significa que si no lo cambiamos estamos entregando a un caco que sabe la dirección de dónde vivimos (nuestra IP) también la llave del portal.

Cambiaremos el puerto para evitarlo. Esto no quita que el caco pueda intentar averiguar “el portal” si sabe cómo hacerlo pero al menos le ponemos impedimentos. También hay scripts que atacan directamente el puerto 22, por lo que el cambio de puerto es algo obligatorio. Poned el que queráis y abridlo también en el router para que podáis acceder a vuestro ordenador desde otro. Usaremos por ejemplo el 4321, podéis poner el que queráis. Así pues en el fichero de configuración:

port 4321

Un poco más abajo buscad la opción “Protocol” debe estar a valor 2, si no es así (valor 1 ó 2,1 ponedla. Hay dos versiones de protocolo SSH. La primera está ya en desuso y tiene varias vulnerabilidades. Así debéis dejarlo en vuestra configuración:

Protocol 2

Buscad la sección “Authentication”. Sus dos primeras opciones son también importantes. La primera es el número de segundos que tendrá el usuario remoto para hacer login en tu máquina. Poned ese valor a pocos segundos, no tardamos mucho en hacer login si sabemos la cuenta y la password. De esta forma evitamos ciertos scripts que se aprovechan de ese tiempo. El valor típico en términos de seguridad es 30, aunque podéis poned incluso menos si estáis más conformes.

LoginGraceTime 30

Justo debajo tenéis otras de las opciones más importantes, PermitRootLogin. Si antes usé la metáfora del caco y el portal, esta opción viene a ser que le digáis también en qué planta del bloque de pisos vivís y qué puerta, faltándole sólo la llave. Con esto lo que insinúo es que si sabe por qué puerto entrar, tan sólo le queda averiguar dos datos: el nombre de una cuenta y su contraseña.

Si tenemos esta opción habilitada (yes) el caco ya tiene la mitad del trabajo hecho, pues el usuario “root” existe en todas las máquinas GNU/Linux, tan sólo le queda averiguar la contraseña. Por eso es más que recomendable deshabilitar esta opción. No os preocupéis los que tenéis en mente usar SSH para hacer un uso administrativo, podéis hacerlo con vuestra cuenta y sudo sin problema alguno. Así pues…

PermitRootLogin no

También podéis señalar con el dedo las cuentas que tienen permitido el uso SSH (AllowUsers). Pongamos un ejemplo, que es como mejor se entienden las cosas: Supongamos que tienes un amigo con el que quieres compartir algo vía SSH y además tiene un hermano que es un enreda y en el que no confías por si te la puede liar. Llamaremos a las cuentas “amigo” y “pesado” respectivamente. Para restringir el uso de SSH a tu amigo y a tu propia cuenta (llamémosla “pepino”) podemos indicárselo mediante configuración. Incluso podemos indicar también que tu amigo sólo se pueda conectar a tu ordenador desde el suyo, sabiendo su IP (supongamos que es 83.45.258.21). Pondríamos en la configuración:

AllowUsers pepino amigo@83.45.258.21

De esta forma tú podrías usar tu cuenta (pepino) para conectar a tu equipo desde cualquier lugar, tu amigo podría hacerlo sólo desde su ordenador (si tiene esa IP) y tu hermano no podría conectar a tu máquina vía SSH, si no tiene tu cuenta.

Otra opción interesante es el número de intentos que tiene el usuario remoto para hacer login (MaxAuthTries). Como comenté antes, quien intente conectar debe acordarse de su login y password, por lo que es tontería darle un número grande de intentos. En principio con dos son más que suficientes. Si al segundo intento no lo ha conseguido se cortará la conexión SSH. Siempre se puede volver a conectar y reintentarlo, pero así nos quitamos de encima ciertos scripts que intentan encontrar el login por fuerza bruta a base de ensayo y error.

MaxAuthTries 2

Por último hay otra opción que define el número máximo de usuarios conectados simultáneamente a tu máquina. Esto ha de adaptarse a tus propias necesidades. Si estamos hablando de un ordenador personal donde sólo vas a conectar tú, pues lo lógico sería que como mucho hubiera una. Si estamos hablando de un ordenador que hará las veces de servidor compartiendo una carpeta a varias máquinas, deberás decidir cuántos son. Cuanto tengas claro el número indícalo en la opción siguiente en lugar de la ‘X’:

MaxStartups X

Ya podéis guardar y cerrar gedit. Con esto tenéis un servidor SSH bastante seguro. Como comenté antes nunca es 100% seguro pero a priori podéis estar bien tranquilos. Sólo resta reiniciar el propio servidor SSH para que tome los cambios que hemos efectuado en su configuración. Escribid en consola:

$ sudo /etc/init.d/ssh restart

Un último consejo. Como habéis visto podemos poner trabas al caco en cuanto a nuestra dirección y puerta, pero ¿podemos ponerle problemas con la llave? La llave se entiende que es la contraseña. Y la respuesta es afirmativa. Podéis hacerlo pero vosotros mismos. Poned claves en condiciones a vuestras cuentas. Usad como poco 5 ó 6 caracteres y a ser posible que se entremezclen mayúsculas, minúsculas y números, por ejemplo: entr3TuXeSyp3p1n0s.

Es un ejemplo exagerado, enrevesado a la hora de escribir e incómodo para meterlo en sudo cada dos por tres, pero intentad que sea del estilo y procurad que no sea algo tan simple como vuestro nombre, el de vuestra mascota, vuestra fecha de nacimiento, grupo favorito, etc.

Uso de SSH en consola
  • Conectar

Ahora que tenemos SSH bien seguro es hora de que veais para qué sirve. Parto de que tenéis dos equipos, el que tenéis delante y al que queréis conectar. Obviamente debéis tener una cuenta en el segundo para poder entrar. La forma de conectar por defecto es la siguiente:

$ ssh tu_cuenta@ip_del_ordenador_remoto

Esto sería si no hubiéramos cambiado el puerto, ya que intentaría conectar por el puerto 22 que es el puerto por defecto del cliente. Podéis cambiarlo si queréis para que conecte por defecto por el puerto que le digáis en lugar del 22 editando el fichero /etc/ssh/ssh_config. Descomentáis (si está comentada) la opción “Port” y en lugar de “22″ ponéis el que queráis.

La otra opción, que es lo más normal, es simplemente indicarle en la línea de conexión qué puerto ha de usar:

$ ssh -p puerto tu_cuenta@ip_del_ordenador_remoto

Para que lo veais más claro os voy a poner un ejemplo. Mi portátil está en la ip 192.168.1.4 y el puerto SSH que tengo para el mismo es el 4884. La cuenta que voy a usar para conectarme es “pepino”, así que para conectar desde mi PC de sobremesa al portatil sería:

$ ssh -p 4884 pepino@192.168.1.4

Tras esto me pedirá la contraseña:

pepino@192.168.1.4's password:

La introducimos y tras un texto de “bienvenida” veremos que nuestro prompt ha cambiado a “nombre_cuenta@nombre_manquina”. Mi portatil se llama salamandra, así pues mi prompt es:

pepino@salamandra:~$

A partir de este instante tu consola está controlando el equipo remoto. Estarás en el home de tu cuenta en la máquina remota. ¿Qué podemos hacer?

  • Copiar ficheros

Seguramente es lo primero que se os ha pasado por la cabeza a algunos. Efectivamente podemos copiar ficheros fácilmente desde el ordenador remoto al que estamos usando en este momento, y es fácil (es una sóla línea):

$ scp ruta/archivo cuenta_en_ordenador_presente@ip_ordenador_presente:ruta/fichero

Complicado a priori, ¿verdad? En el fondo no lo es, una vez sabéis qué es cada cosa. ruta/fichero es el lugar donde está el archivo a copiar en la primera aparición, y el lugar donde se va a copiar en la segunda. cuenta_en_ordenador_presente es la cuenta que estáis usando (u otra) en el ordenador que tenéis delante (no el remoto). La ip_ordenador_presente es precisamente la ip de vuestro ordenador. Pero como siempre mejor con un ejemplo.

Supongamos que quiero copiarme un fichero llamado pepino.jpg que está en el escritorio de la cuenta “pepino” del portátil (el ordenador remoto) y quiero copiármelo en el home de la cuenta “tux” de mi ordenador presente, cuya ip es 192.168.1.6. Ya que estoy quiero aprovechar y cambiarle el nombre. Quiero que se llame pepinaceo.jpg en lugar de pepino.jpg. Escribiremos en el SSH (es una sóla línea):

$ scp /home/pepino/Desktop/pepino.jpg tux@192.168.1.6:/home/tux/pepinaceo.jpg

¿No funciona? ¿Sabes por qué? El puerto, recordad que lo cambiamos y aquí también tenemos que indicárselo. En el ordenador de sobremesa tengo abierto el puerto 8448, así pues (es una sóla línea):

$ scp -P 8448 /home/pepino/Desktop/pepino.jpg tux@192.168.1.6:/home/tux/pepinaceo.jpg

Nos pedirá la contraseña de la cuenta “tux” en el ordenador que tenemos delante y copiará el archivo:

pepino@192.168.1.4's password:
pepinaceo.png 100% 292KB 291.7KB/s 00:00

Y si ya estuvieramos en el escritorio (prompt: pepino@salamandra:~/Desktop$) no habría que poner toda la ruta si no queremos ya que tomaría la ruta relativa a la actual:

$ scp -P 8448 pepino.jpg tux@192.168.1.6:/home/tux/pepinaceo.jpg

(Nota) Ojo con la ‘P’ que en este caso debe ser mayúscula.

Otra gracia del asunto es que no tienes por qué copiarlo a tu equipo actual. Si tienes acceso a otro ordenador más, puedes copiar algo de uno al otro del mismo modo, es decir, teniendo login en ambos y sabiendo su IP. Por otro lado si lo que queremos copiar es una carpeta, basta con añadirle el parámetro ‘-r’ para que copie todo su contenido (r=recursivo).

  • Otros usos

Básicamente cualquiera que se os pase por la cabeza. Daros cuenta que para un sistema GNU/Linux el interfaz no lo es todo, de hecho es prácticamente una aplicación que está corriendo bajo el propio sistema operativo, por lo que podéis administrar perfectamente vuestro equipo desde una consola y con acceso remoto vía SSH. Dentro de una conexión SSH, podéis reiniciarlo:

pepino@salamandra:~$ sudo reboot
Broadcast message from pepino@salamandra
(/dev/pts/1) at 23:45 ...
The system is going down for reboot NOW!

O apagarlo:

pepino@salamandra:~$ sudo halt
Broadcast message from pepino@salamandra
(/dev/pts/1) at 23:51 ...
The system is going down for halt NOW!

O usar cualquier otra aplicación de texto, como podría ser una que os presenté hace poco y que os podría venir muy bien en este caso: links. De esta forma si queréis podeís navegar en la consola y descargaros algo en vuestra máquina estando en otra.

El abanico de posibilidades es realmente inmenso.

SSH en Nautilus

Lo cierto es que si lo que queremos es simplemente copiar archivos o ver el contenido de alguno de ellos que están en otra máquina, podemos usar nautilus que siempre será más amigable para algunos que a través de consola.

No hay mucho cambio al respecto. Alt+F2 y escribid dentro “nautilus”. Se os abrirá el navegador de archivos. Nautilus tiene dos formas de mostrarte dónde estás dentro de la jerarquía de directorios. Una es a través de botones donde cada carpeta es un botón que puedes pulsar para volver atrás:

Y otra que te indica la ruta en modo texto:

Para cambiar de un modo al otro pinchad en el icono que está a la izquierda del todo que es un folio escrito y un lápiz. Nos quedaremos en el segundo modo y en la caja de texto de “Lugar:” escribiremos la orden de conexión:

ssh://tu_cuenta@ip_pc_remoto

Siguiendo con los ejemplos anteriores:

ssh://pepino@192.168.1.4

Esto sería si el puerto es el que está por defecto, como nosotros lo cambiamos tenemos que indicárselo con “:puerto” tras la ip. En nuestro ejemplo:

ssh://pepino@192.168.1.4:4884

Ahora nos pedirá la contraseña de la cuenta.

Tomad la decisión que queráis. Personalmente yo soy de los prefieren tomarse la molestia de introducir la clave en cuestiones tan importantes como es la seguridad de SSH.

Tras esto nos colocará en la raíz de la máquina remota. Si lo que queríamos era que nos dejara en una carpeta determinada se lo podemos indicar en la línea de conexión. Por ejemplo en el escritorio de nuestra cuenta:

ssh://pepino@192.168.1.4:4884/home/pepino/Desktop/

Ahora podéis copiar archivos y carpetas con total comodidad desde vuestro escritorio GNOME.

Ejecutar aplicaciones gráficas remotamente

Otra cosa muy práctica que podemos hacer gracias a SSH es ejecutar una aplicación que no tenemos en el equipo actual pero sí en el remoto y trabajar allí. Es decir, puedes mirarlo como un servidor de trabajo gráfico. Si aún no queda claro os pongo otro ejemplo:

Mientras estábais fuera de casa el pesado de tu hermano se ha hecho con tu ordenador porque tiene que hacer algo y si no “se lo dice a mamá“. Sin embargo tú también tienes cosas que hacer en él. No hay problema. Te pones en el equipo de tu hermano y abres la aplicación que necesites de tu propio ordenador en el PC de tu hermano.

Práctico, ¿verdad? Pues es muy sencillo, basta con añadir un argumento más (-X) y el nombre de la aplicación que queremos usar. Por ejemplo imaginemos que queremos jugar a Doom en DOSBox, y en el ordenador de tu hermano no tenemos ninguna de las dos cosas. Podemos instalar DOSBox, copiar la carpeta de Doom, montarla y jugar. O también podemos ejecutar directamente DOSBox remotamente y montar el juego que ya tenemos en nuestro equipo:

$ ssh -X -p 4884 pepino@192.168.1.4 dosbox

Ahora tan sólo resta montar la carpeta como ya os mostré. Podéis introducir la ruta de vuestro PC pues en el fondo es en vuestro PC donde se está ejecutando todo.

Cambiar el mensaje de bienvenida

Ya saliendo de la parte práctica, he querido hacer esta pequeña sección dentro del manual para los fanáticos de la personalización como yo. Si recordáis cuando os expliqué la conexión por consola, os comenté que tras introducir la clave nos daba una especie de texto de bienvenida. Este texto de bienvenida es modificable y puedes poner lo que quieras. Este es el de mi equipo de sobremesa:

Para hacerlo es simple. Tienes que editar (con privilegios de administrador) el archivo /var/run/motd y escribir dentro lo que quieras que aparezca cuando alguien se conecte. Es decir:

$ sudo gedit /var/run/motd

Lo modificamos a nuestro gusto, guardamos y cerramos gedit.

Fuente: http://tuxpepino.wordpress.com/2007/05/11/ssh-el-dios-de-la-administracion-remota/


Tuneles SSH

| 0 comentarios

Hay momentos donde necesitamos tener plena seguridad de que los datos que son transmitidos desde nuestra máquina hacia internet no son leídos por terceros (¡eso sería siempre!), cómo cuando vamos a un café con wireless disponible ó un congreso lleno de ávidos “hackers” todos con sus sniffers llenando sus logs de contraseñas de terceros y luego aparecen los blogs de “hackers éticos” “defaceados” (ñ_ñ). En fin, necesitamos seguridad, y no todo lo que usamos se encuentra bajo SSL, ó no sabes que tiene la opción, por ejemplo, ¡levante la mano quien usa twitter con https!. Hay otras situaciones molestas como cuando un maldito proxy nos filtra contenido, no podemos ver todos los sitios ó usar todos los servicios que necesitamos, o simplemente nos cierran puertos que necesitamos, como el sagrado IRC.

Bien, para todos estos males existen los túneles SSH, quienes realizan una conexión segura, encriptada, y desde un servidor remoto, por lo que nuestro origen queda anónimo. Todo lo que necesitas es una máquina en una red externa (típicamente un servidor) en la que tengamos acceso ssh. Según la necesidad, podemos requerir de 3 diferentes esquemas:

  1. Estás tras un proxy y no te deja salir a todas las redes o te filtra sitios que realmente necesitas. ¡Tú necesitas Dynamic application-level port forwading!
  2. Te cerraron los puertos y necesitas acceder a algún servicio del servidor A con el puerto XX. ¡Tú necesitas Local Port forwarding!
  3. Estás tras un router, con ip privada y necesitas que alguien entre a algún servicio de tu máquina sea HTTP, SSH, FTP, etc. ¡Tú necesitas Reverse Port Forwarding! (también llamado Remote port forwarding)

1. Dynamic application-level port forwarding

El esquema mas sencillo, funciona como un proxy para cualquier aplicación para cualquier servicio, SMTP, HTTP, POP, IMAP, etc. Bajo este esquema, puedes redireccionar todo el tráfico de un puerto local hacia un servidor remoto a través de otro servidor “de redirección” para cualquier tipo de aplicación que trabaje con protocolo Socks, aunque en la mayoría de los casos si no lo soporta puedes forzarlo con una utilidad que veremos mas adelante. En pocas palabras, haces que un servidor B baje por ti el contenido del servidor A y lo reenvíe a tu máquina local.

El escenario es el siguiente, tienes tu maquina “local” restringida, y tienes acceso a “shell.server.tld” y quieres usar la conexión abierta de “shell.server.tld” para que te reenvíe todo hacia “local”, esto lo hacemos mediante:

fulanito@local $ ssh -N -D 8888 shell.server.tld

La opción -N es para que no lanze ningún comando al hacer la conexión, solo establezca el tunel. Puedes añadir -f para que además se vaya a background. Y claro añade las opciones que necesites como -pPuerto -lUser, etc. para realizar la conexión ssh.

Y listo!, ahora vamos al Firefox (¿que?, ¿que no usas firefox? ¿en que mundo vives? osea jelou!) y en Edit->Preferences->Advanced->Network->Settings , seleccionamos “Manual proxy configuration” y en la entrada de text de “Socks Host” metemos 127.0.0.1 puerto 8888, desde luego puedes cambiar el puerto por otro aquí y en el comando ssh. ¡Presto! ahora ve a tu firefox y abre, digamos, http://www.whatismyip.org/, verás como ya estás saliendo desde la ip del servidor “shell.server.tld”

Si estas usando algún programa que no soporte Socks, puedes instalar “tsocks” y configurar en /etc/tsocks.conf la conexión. Por ejemplo hasta el final del archivo yo tengo:


server = 127.0.0.1
server_type = 5
server_port = 8888

Ahora, abre el tunel con el comando antes descrito, y posteriormente corre tu programa anteponiendo “tsocks”, por ejemplo:

fulanito@local $ tsocks opera

Et voilá!. Está de mas decir que puedes abrir mas de una conexión y usar varios navegadores saliendo por diferentes IP’s. Muy útil cuando andas mmm digamos, analizando un sitio de forma anónima ;-) .

Local Port forwarding

Ahora sí vamos a forwardear puertos de verdad, El anterior esquema es a nivel aplicación, SSH entiende que debe servir de proxy para lo que le pida la aplicación, si pides la página de google por socks, ssh entiende que tiene que conectarse a google y reenviar el contenido a tu máquina local a través de un tercer servidor, y dinámicamente cambia del servidor de google al de yahoo, o hotmail, o facebook, etc. En este esquema de Local Port forwarding (y también el Remote/reverse port forwading) SSH simplemente reenvía todo lo que mandes a un puerto local hacia un servidor destino a través de un servidor donde tienes shell. Es decir, sólo puedes redirigir el tráfico hacia un sólo servidor. Usemos el vano ejemplo del IRC, no se porque siempre nos bloquean el puerto IRC (6667) así que tenemos el escenario:

Estamos en maquina “local”, tenemos acceso shell a “shell.server.tld” y queremos conectarnos a irc.freenode.net. Lo que tenemos que hacer es lo siguiente:

fulanito@local $ ssh -N -L 3337:irc.freenode.net:6667 shell.server.tld

Y listo, tenemos un tunel desde nuestra máquina en el puerto 3337 a irc.freenode.net:6667 a través de shell.server.tld. Ahora todo lo que nos queda hacer es:

fulanito@local $ irssi -c localhost -p 3337

Y irssi nos mostrará el MOTD (Message Of The Day) de freenode, tal y como si nos estuvieramos conectando directamente desde shell.server.tld.

Y claro, podemos usar el tunel para diversos servicios:

  1. Para conectar a un proxy externo: fulanito@local $ ssh -N -L 1080:proxy.server.com:8080 shell.server.tld
  2. Para conectarse a un servidor POP: fulanito@local $ ssh -N -L 1110:pop.server.com:110 shell.server.tld
  3. Para conectarnos al webserver de una máquina de la chamba: fulanito@casa $ ssh -N -L 8080:maquinadelachamba:80 maquina-con-ip-externa-de-la-chamba.dyndns.com
    Con este ejemplo aprovecho para mencionar un pequeño detalle: cuando especificamos “-L puerto:hostdestino:puerto shell.server.tld“, ponemos a hostdestino tal y como shell.server.tld lo vé, es decir, si shell.server.tld puede ver a maquinas con ip’s privadas dentro de su red, podremos especificar en -L una ip privada, por ejemplo: ssh -N -L 8080:192.168.1.100:80 189.10.20.30

Reverse/Remote Port forwarding

Este esquema es quizás el más divertido y confuso de los tres, basicamente es lo mismo que -L pero “en inversa”, expliquemos.

Con -L le dices a ssh que reenvíe el tráfico que vaya a un puerto local hacia uno remoto, con -R le dices a ssh que reenvíe el tráfico que llegué a un puerto remoto hacia uno local. ¿Para que nos sirve algo así?, pongamos dos escenarios:

1. El Soporte Técnico.
Tienes un problema con tu linux/mac os x/unix/whatever, y quieres que un amigo se conecte a tu máquina para ayudarte y estas detrás de un router, con ip privada, y sin privilegios para poder abrir un puerto en el router que redirija el tráfico a tu máquina. Solución, abres un tunel “reverso”:

fulanito@local $ ssh -N -R 2200:localhost:22 shell.server.tld

Lo cual quiere decir: “abre un tunel desde shell.server.tld en el puerto 2200 que reenvíe el tráfico hacia mi máquina (localhost) en el puerto 22″. Y ahora le dices a tu amigo que se conecte a shell.server.tld y desde ahí el tiene que correr:

sutanito@shell $ ssh -p2200 localhost

Y se reenviará la conexión hasta tu máquina, en otras palabras, podrá conectarse a tu máquina desde otra, pero sólo mientras mantienes abierto el tunel. Por default, todos los túneles escuchan sólo a la interfaz loopback, es decir, solo aceptan conexiones desde la misma máquina en donde se está abriendo el tunel, es por ello que tu amigo debe primero entrar a shell.server.tld y luego conectarse a “localhost”. Existe la posibilidad de que tu amigo se conecte directamente a shell.server.tld:2200 desde su máquina, eso lo veremos en el siguiente ejemplo:

2. Publicar un servicio.
Ahora, digamos que estas en un starbucks, o algo así. Y necesitas enseñar lo que tienes en tu webserver local a un cliente, como ya establecimos, no puedes abrirte un puerto para que el cliente mire hasta tu máquina con ip privada. Solución, abres un tunel “reverso”:

fulanito@local $ ssh -N -R 8888:localhost:80 shell.server.tld

Y listo, el túnel leerá la página de tu máquina y la servirá a través de shell.server.tld:8888, entonces le das a tu cliente la dirección http://shell.server.tld:8888/

Pero como decíamos en el anterior ejemplo, los túneles solo atienden a “localhost” por lo que para que tú cliente pueda acceder directo a shell.server.tld:8888, debemos agregar una opción al final del archivo /etc/ssh/sshd_config:

GatewayPorts yes

Y listo ahora los túneles escucharán en cualquier interfaz.

Nota:
Ten en mente siempre, la información viajará encriptada solamente desde tu máquina local hacia el servidor donde estás estableciendo el tunel, de acuerdo a nuestros ejemplos, la información viajará encriptada desde local <=> shell.server.tld, pero desde shell.server.tld <–> irc.freenode.net (u otro destino final) no estará encriptada. En el 99% de los casos esto servirá para mantener tus datos seguros.

Fuente: http://sololinex.wordpress.com/2009/01/02/tuneles-ssh/