1.- Introducción

Actualmente las Redes de Computadoras son los medios digitales más usados en todos los ámbitos de la sociedad para la transferencia de información. Normalmente estos medios se encuentran en redes públicas, por lo cual están expuestas a intervenciones de una u otra forma.

Cuando se realiza una conexión a un servidor remoto usando por ejemplo el comando telnet o ftp, el login(usuario) y password(contraseña) son transmitidos en la red de forma clara, lo cual representa un gran riesgo si llega a existir sobre la red un programa que capture la información, basándose en el modo promiscuo de las redes ethernet (comúnmente llamado sniffer), ocasionado obtener tanto el login como el password y pudiendo posteriormente irrumpir en el servidor con esta información.

Este tipo de problemáticas ha llevado al diseño de herramientas que permitan evitar estas situaciones siendo el caso de Secure Shell (ssh), desarrollado por Tatu Ylonen en la Universidad Tecnológica de Helsinki en Finlandia y OpenSSH, que nace del proyecto de un sistema operativo orientado con la filosofía de la seguridad en mente como lo es OpenBSD.

Secure Shell y OpenSSH permiten realizar la comunicación y transferencia de información de forma cifrada proporcionando fuerte autenticación sobre el medio inseguro.
 
 
 

1.1.- Historia del SSH

SSH 1.2.12 fue desarrollado por un programador finlandés, Tatu Ylönen, que publicó su trabajo bajo una licencia libre. Pronto el éxito de su programa lo llevo a patentar la marca registrada "SSH?" y crear una empresa con fines comerciales. Las siguientes versiones dejaron de ser libres y se permitió su empleo únicamente para usos no comerciales. Los desarrolladores de OpenBSD se dieron cuenta de que su sistema operativo, centrado en la criptografía y seguridad, se quedaba "cojo" sin SSH. Además, las encuestas afirmaban que lo primero que la mayoría de usuarios de OpenBSD añadía después de instalar el sistema era SSH. Con estas ideas en la cabeza y bastante buenas intenciones, surgió el proyecto OpenSSH, cuyo principal objetivo consistió en desarrollar una implementación totalmente libre de SSH. Los primeros pasos de este proyecto estuvieron centrados en utilizar solamente código libre y portable. Tanto es así que pusieron especial empeño en evitar problemas con patentes y restricciones gubernamentales: la mayoría de los desarrolladores residían fuera de Estados Unidos, a excepción de Niels Provos, un alemán afincado en Michigan, que cruzó la frontera a Canadá para enviar su código desde una pequeña tienda local de informática en Ontario (nada quería dejarse a la ligera).

Todos estos esfuerzos no fueron vistos con tan buenos ojos por el desarrollador inicial de SSH, que veía como su proyecto comercial se iba al traste. Después de varias demandas judiciales y muchas discusiones, OpenSSH pudo mantener el "SSH" en su nombre y seguir con el trabajo que estaban realizando.
 
 
 

2.- ¿Qué es Secure Shell?

Secure Shell (ssh) es un programa que permite realizar conexiones entre máquinas a través de una red abierta de forma segura, así como ejecutar programas en una máquina remota y copiar archivos de una máquina a otra. Tal y como se explica en el RFC de Secure Shell:

SSH(Secure Shell) es un programa para conectarse a otros equipos a través de una red, para ejecutar comandos en una máquina remota y para mover archivos de una máquina a otra. Proporciona una exhaustiva autenticación y comunicaciones seguras en redes no seguras"

Ssh provee fuerte autenticación y comunicación segura sobre un canal inseguro y nace como un reemplazo a los comandos telnet, ftp, rlogin, rsh, y rcp, los cuales proporcionan gran flexibilidad en la administración de una red, pero sin embargo, presenta grandes riesgos en la seguridad de un sistema. Adicionalmente, ssh provee seguridad para conexiones de servicios X Windows y envío seguro de conexiones arbitrarias TCP.

Para la autentificación, ssh puede utilizar algoritmo de cifrado como RSA o DSA. Para el envío de datos a través de la red, usa 3DES, IDEA, Blowfish...

Soporta ambas versiones del protocolo ssh, la 1 y la 2. Dependiendo de cuál usemos los métodos de autentificación, son distintos:

ssh v1:

Si la máquina que se va a conectar está en /etc/hosts.equiv o /etc/shosts.equiv del servidor y el username es igual en ambas máquinas, se permite el login. Luego si .rhosts o .shosts existe en el servidor y contiene una línea con el nombre de usuario del cliente, se permite el login. Este método "en solitario", no es permitido por medidas de seguridad.

Este segundo método es el anterior junto con autentificación por host mediante claves RSA. Consiste en que si el login es permitido por /etc/hosts.equiv, /etc/shosts.equiv, $HOME/.rhosts o $HOME/.shosts y el servidor puede verificar la "clave de host" del cliente (ver /etc/ssh/ssh_known_hosts y $HOME/.ssh/known_hosts) , será admitida la conexión.

El tercer método es autentificación por RSA, es decir, el cliente crea su clave pública y su clave privada; el servidor conocerá la clave pública de cada usuario. El archivo $HOME/.ssh/authorized_keys contiene las claves que son permitidas para el login. Al conectarse, el cliente le dice al servidor con qué pareja /pub/priv quiere autentificarse. El servidor le envia un "desafío" al cliente, y si el cliente lo descifra y envía correctamente la respuesta, se permite el login. El cliente, generará sus claves mediante el programa ssh-keygen y se guardan en $HOME/.ssh/identity (para la clave privada) y $HOME/.ssh/identity.pub. El cliente debe copiar el archivo identity.pub en su home del servidor, más concretamente en HOME/.ssh/authorized_keys . Después de esto, se puede conectar sin necesidad de password.

Si fallan, autentificación por contraseña.

Cuando el cliente se conecta usando el protocolo v2 de ssh, se usan métodos similares de autentificación que en v1. Primeramente se intenta con la autentificación de host, luego por clave pública/privada y finalmente por password. El método que hemos visto en la v1 de autentificación por RSA, cambia un poco en esta segunda versión, ya que podemos usar tanto RSA como DSA. El cliente tendrá su clave privada $HOME/.ssh/id_dsa o $HOME/.ssh/id_rsa. El servidor también tendrá que comprobar las claves en $HOME/.ssh/authorized_keys.

sshd : servidor de ssh

sftp-server : servidor ftp mediante ssh. Para usarlo, añadir "Subsystem sftp /usr/lib/sftp-server" en sshd_config

ssh : el cliente, con él nos podemos conectar al servidor sshd.

scp : copia archivos entre máquinas. Sustituto para rcp.

ssh-keygen : para crear claves públicas y privadas RSA o DSA (host keys y user authentication keys).

ssh-keyscan : utilidad para obtención de claves públicas de hosts

ssh-copy-id : copia el identify.pub en una máquina remota

ssh-agent : agente de autentificación. (Usado para manejar RSA keys en la autentificación.)

ssh-add : para añadir nuevas claves con el agente.

sftp : cliente ftp mediante ssh

3. ¿ De que Previene Secure Shell?

Debido a la promiscuidad de la interfaz ethernet, se genera una problemática sobre los siguientes servicios de red usados en la actualidad, tales como:

telnet

ftp

http

rsh

rlogin

rexec

Por ello para evitar que determinadas personas capturen el trafico diario de la red, es conveniente instalar el Secure Shell(SSH).

Entre los ataques más comunes que nos previenen Secure Shell están:

Sniffering(Captura de trafico)

IP Spoofing

MACpoofing

DNS Spoofing

Telnet Hickjacking

ARP Spoofing

ARP Spoofing

IP Routing Spoofing

ICMP Spoofing

4.- ¿Qué es un túnel SSH?

La mayoría de los protocolos que empleamos en nuestras comunicaciones están basados en diseños de hace casi 30 años, cuando la seguridad en redes telemáticas no era un problema. Telnet, FTP, POP3, protocolos de uso cotidiano, descuidan la seguridad y confidencialidad de los datos que envían. De nada sirve proteger nuestros servidores, implantar una buena política de contraseñas y actualizar las versiones de nuestros demonios, si luego cuando un usuario de POP3, por ejemplo, quiere ver su correo electrónico desde la universidad, envía su usuario y contraseña en texto plano por la red. Para evitar esto tenemos dos alternativas: bien elegir protocolos que sean seguros, bien hacer seguros los protocolos inseguros. De las dos opciones, la segunda permite reutilizar muchos más clientes y servidores ya programados, ayuda a enmascarar la complejidad de la seguridad en la transmisión y es una solución siempre escalable. Por todo esto, vamos a ver cómo convertir nuestros protocolos tradicionales en protocolos seguros, y qué tiene que ver SSH en todo ello.

La idea en la que se basa este procedimiento es la de hacer un túnel por el cual viajarán los datos de manera segura ("tunneling"). El símil con la vida real está bastante bien escogido: imaginemos que la tasa de mortalidad de los diferentes medios de transporte fuese equivalente a la posibilidad de que la seguridad de nuestros datos sea violada, y que el tren representase un canal seguro y el automóvil un canal inseguro. El túnel del Canal de la Mancha sería el ejemplo perfecto para ilustrar el concepto de "tunneling": cuando queremos viajar a través de él con nuestro coche, tenemos que subirnos a un vagón para coches y luego cruzar el túnel en tren. Hemos incrementado sensiblemente la seguridad del viaje, porque la probabilidad de un accidente de tren es muchísimo menor que la de un accidente de coche. Este mismo proceso es el que se da a la hora de establecer un túnel seguro en la comunicación entre cliente y servidor. En cada uno de los extremos del túnel están las aplicaciones estándar (un demonio POP3 estándar, nuestro cliente de correo favorito...) y la comunicación se asegura haciendo uso de toda la potencia criptográfica de SSH. Para ello tenemos que realizar un procedimiento similar al que supondría subir nuestro coche al tren, establecer mediante SSH un reenvío de los datos gracias a una técnica denominada "port-forwarding". SSH recoge los datos que el cliente quiere enviar y los reenvía por el túnel o canal seguro, al otro lado del túnel se recogen los datos y se reenvían al servidor conveniente.
 
 
 

5.- ¿Dónde obtener el Secure Shell?

5.1.Secure Shell cliente/servidor para sistemas Unix

Sitio FTP de Secure Shell

http://ftp.ssh.com/pub/ssh

Departamento de Seguridad en Cómputo

ftp://ftp.seguridad.unam.mx/Herramientas/Unix/Comunicacion

5.2 OpenSSH Cliente/Servidor para sistemas Unix

Sitio FTP de OpenSSH

http://www.openssh.com/ftp.html

Departamento de Seguridad en Cómputo

ftp://ftp.seguridad.unam.mx/Herramientas/Unix/Comunicacion

5.3 Secure Shell cliente para sistemas Windows

Sitio FTP de Secure Shell (Solo para clientes con protocolo SSH2)

http://ftp.ssh.com/pub/ssh

Departamento de Seguridad en Cómputo

ftp://ftp.seguridad.unam.mx/Herramientas/Windows/Comunicacion

5.4 Secure Shell cliente para sistemas Mac

Departamento de Seguridad en Cómputo

ftp://ftp.seguridad.unam.mx/Herramientas/Mac/Comunicacion/Ssh1
 

6.- Configurando SSH

Una vez tengamos instalado SSH debemos configurar dos archivos primarios, a continuación unos extractos útiles de estos archivos:

/etc/ssh_config (Configuración del cliente de OpenSSH):

UseRsh no

FallBackToRsh no # OpenSSH no caera en el protocolo RSH de texto claro.

ForwardX11 no # No se permite el reenvío de las ventanas X por medio de la sesión SSH.

/etc/sshd_config (Configuración del Servidor de OpenSSH):

Port 22

ListenAddress 0.0.0.0 # Escucha en todas las interfaces activas

HostKey /etc/ssh_host_key # Almacena la llave en la localización por default

ServerKeyBits 1664 # Generar una llave con un bit de 1664 (encriptación mas fuerte que la asignada por default)

LoginGraceTime 600 0 # Permite 600 segundos a un cliente para conectarse

KeyRegenerationInterval 3600 # Genera una llave nueva cada 3600 seconds (cada hora)

PermitRootLogin no # No se permite a los clientes conectarse como ``root'', se debe utilizar “''su''

X11Forwarding no # No se permite el reenvío de los paquetes correspondientes a las conexiones del sistema X a traves de la sesión SSH.

PermitEmptyPasswords no # Una contraseña DEBE ser escrita, es decir las conexiones sin contraseña no son permitidas.
 

7.- Usando SSH

7.1. Sesión entre máquinas en UNIX

Ssh permite mantener sesiones interactivas con una máquina remota de la forma como lo hace el comando telnet.

ssh [-a] [-c idea|blowfish|des|3des|arcfour|none] [-e esc] [-i identity_file] [-l login_name] [-n] [-k] [-V] [-o] [-p port] [-q] [-P] [-t] [-v] [-x] [-X] [-C] [-g] [-L port:host:hostport] [-R port:host:hostport] hostname [command]

A continuación se describen brevemente las principales opciones del comando ssh.

-a Deshabilita el agente de autenticación

-c idea|des|3des|... Selecciona el algoritmo de cifrado utilizado para cifrar la sesión.

-e Habilita el carácter de escape para una determinada sesión (default:~).

-i identity-file Selecciona el archivo donde leerán la llave de autenticación. Por default utiliza .ssh/identity dentro del home del usuario.

-l login-name Especifica la cuenta remota por medio de la cual se desea tener acceso.

-p port Puerto remoto de conexión.

-q Causa que todas las advertencias y mensajes de diagnostico sean suprimidos, solo los mensajes de errores fatales son desplegados.

-v Causa que ssh despliegue mensajes de depuración acerca del proceso de conexión.

-x Deshabilita el reenvio (forwarding) de X11.

-C Compresión de todos los datos transmitidos durante la conexión

7.2. Ejemplos:

$ ssh -l micuenta maquina.remota

En este ejemplo utilizamos la opción -l para proporcionar el login con el que tendremos acceso a la máquina remota. En este caso la cuenta es micuenta y la máquina es maquina.remota.

$ ssh micuenta@maquina.remota

También podemos hacer uso del formato descrito arriba para entrar a una cuenta dentro de una máquina remota.

$ ssh maquina.remota

En caso de poseer el mismo nombre de cuenta en ambas máquinas (local y remota) es posible tener acceso a la máquina remota proporcionando solamente el nombre de la máquina.

7.3. Transferencia de archivos

Secure Shell proporciona una herramienta que permite realizar transferencia de archivos entre distintos hosts, haciendo uso de las características de ssh, este comando es scp, el cual cuenta con las siguientes opciones:

scp [-aAqrvBCL1] [-S path-to-ssh] [-o ssh-options] [-P port] [-c cipher] [-i identity][[user@]host1:]filename1,... [[user@]host2:]filename2

-a Habilita la estadística de transferencia de cada archivo que se transfiere.

-A Deshabilita el mensaje de estadística de transferencia

-c cipher Selecciona el algoritmo de cifrado a utilizar en la transferencia de datos.

-i identity Selecciona el archivo donde se tendrá acceso a la llave RSA.

-L Uso de puerto no privilegiado. Esta opción posee algunas restricciones como son la imposibilidad de usar rhosts o autenticación rsarhosts

-1 Forzar a scp a usar el comando scp1 por parte de host remoto, Esto puede ser necesario en el caso que el host remoto utilice scp2.

-o ssh-options Opciones que se pasarán al ssh.

-p Preserva las distintas fechas y horas de acceso, modificación y atributos del archivo original

-q Deshabilita el despliegue de estadísticas de transferencia

-r Copia recursiva de directorios completos

-v Causa que scp y ssh desplieguen mensajes de estado relacionados con el proceso de conexión, etc. Adecuado para depurar errores existentes en las conexiones realizadas.

7.4. Ejemplos:

$ scp micuenta@máquina.remota:/tmpu/archivo /copias

En este caso se copiará /tmpu/archivo localizado en la máquina remota maquina.remota al directorio /copias en la máquina local. Se utilizó la cuenta micuenta para acceder al servidor.

$ scp /copias/archivo micuenta@máquina.remota:~/bck

En este caso se realizará la copia del archivo /copias/archivo localizado en la máquina local a la máquina remota máquina.remota colocando el archivo en el directorio bck del home de micuenta.

7.5. Uso de .shosts en Secure Shell 1

Los archivos .shosts al igual que los archivos .rhosts permite realizar conexiones entre hosts sobre mecanismo de confianza, en el caso de .shosts este mecanismo de confianza se habilita sobre las características que proporciona Secure Shell, por esto, en aquellas máquinas en las cuales el uso de .rhosts es indispensable sugerimos la sustitución de todos los .rhosts por .shosts.

Para esto se requiere de realizar la siguiente serie de pasos:

1.- En la máquina cliente realizar una conexión hacia la máquina servidor que se va a hacer uso de .shosts.

$ ssh -l cuenta maquina.cliente.de.shosts

Esto es para que la máquina a la que se entrará utilizando mecanismo .shosts obtenga la llave pública de la máquina cliente.

2.- En la máquina servidor debemos de crear sobre el home del usuario el archivo .shosts conteniendo el nombre de la máquina o la IP cliente.

$ more .shots maquina.cliente.de.shosts

3.- Desde la máquina cliente realizamos el enlace.

$ ssh -l cuenta maquina.con.shosts

NOTA: Este tipo de conexión no solicitará el password.

Este tipo de conexión presenta un riesgo, sin embargo, introduce mecanismos propios de ssh, un método con mayores niveles de seguridad se puede obtener utilizando llave RSA.

7.6. Accesos de Mecanismos de Confianza

Para realizar una conexión segura mediante mecanismos de confianza en SSH2 realice lo siguiente:

1.- Generar par de llaves dsa mediante el comando ssh-keygen.

Cliente> ssh-keygen -d

ssh-keygen -d

Generating public/private dsa key pair.

Enter file in which to save the key (/home/usuario/.ssh/id_dsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/usuario/.ssh/id_dsa.

Your public key has been saved in /home/usuario/.ssh/id_dsa.pub.

The key fingerprint is:

1a:84:34:9f:d1:97:76:03:c0:c7:be:12:b0:95:1e:37 usuario@Cliente

Se generan dos archivos en el directorio ~/.ssh/.

id_dsa.pub(publica)

id_dsa (privada)

2.- Exportar id_dsa.pub al servidor al que se realizará la conexión, e incluirlo su contenido en el archivo ~/.ssh/authorized_keys2.

Servidor>cat id_dsa.pub.Cliente >> ~/.ssh/authorized_keys2

Quedando algo así:

Servidor> cat ~/.ssh/authorized_keys2

ssh-rsa mslHXihCHvYNADHKvFPSESKHUpwF0TbpmvMesSGifqhQftn8BOU=usuario@Cliente

3.- Probar la conexión.

Cliente> ssh cuenta@Servidor

Servidor>
 

8.- Posibilidades del SSH

Una vez entendido el método general para crear un túnel SSH, vamos a ver la multitud de aplicaciones posibles que tiene esta técnica:
 

Servicio	Puerto	Comentarios
FTP	21	Se han escrito ya varios textos acerca del SSH tunneling en servidores FTP ampliamente usados en nuestras máquinas Linux como puedan ser ProFTPd o wu-ftpd, si estás interesado en un demonio en particular, te recomendaría que buscaras información sobre él en particular. A nivel general, el SSH tunneling en FTP tiene algunos aspectos reseñables: Como bien sabemos, FTP tiene dos conexiones distintas: una para los comandos (control) y otra para la transmisión de ficheros (datos). La manera estándar de hacer un túnel SSH en una conexión FTP se centra únicamente en la protección de la conexión de control, es decir, del login/password de la sesión y de los comandos utilizados. Los ficheros se ç intercambiarán sin utilizar el túnel SSH.  Es necesario usar el modo pasivo ("pasive mode") para la conexión de datos o de lo contrario el servidor FTP tratará de conectar con la máquina remota que se encuentre al otro lado del túnel SSH (típicamente la propia máquina servidora) y no con la máquina cliente que realiza la petición.  Al usar el modo pasivo, la conexión de datos provendrá de una dirección IP distinta a la usada en la conexión de datos. Esto suele ser un problema para la gran mayoría de servidores FTP, ya que por defecto deniegan este hecho como medida de seguridad (para prevenir "hijacking" o "spoofing" en las conexiones). Deberemos, por lo tanto, configurar el servidor FTP para permitir esto.  Debido a estos problemas de seguridad, y gracias a las nuevas prestaciones de la versión 2 de SSH, el SSH tunneling en conexiones FTP está siendo reemplazado por conexiones "sftp", que proporcionan protección tanto de datos como de comandos, sin necesidad de modificar el servidor FTP existente (realmente este último no es necesario, todo se realiza desde el servidor SSH).
Telnet	23	Realizar conexiones Telnet o rsh mediante túneles SSH no tiene ningún sentido, ya que SSH es ya el protocolo para shell remota de forma segura. En escenarios realmente extraños podría emplearse eventualmente para acceder, por ejemplo, desde un host de Internet a un servidor de una extranet que sólo tiene el puerto 23 abierto. En este caso podría establecerse una conexión SSH segura a un host en la frontera de la extranet con Internet, y de ahí realizar la comunicación al puerto 23 de forma insegura (suponiendo que el interior de la extranet no sea conflictivo).
SMTP	25	Ahora que a consecuencia del spam casi todos los servidores SMTP tienen unas políticas de "relay" muy severas, el SSH tunneling en conexiones SMTP puede aumentar la comodidad de muchos usuarios. La práctica totalidad de servidores SMTP tienen a ellos mismos (localhost) como "relay" aceptado, por lo que si establecemos un conexión segura mediante un túnel SSH a ese servidor y enviamos nuestro correo saliente por el túnel, el servidor lo considerará como proviniente de localhost a pesar de que nos encontremos en un host lejano, por lo que no denegará el envío.
HTTP	80	Muchos servidores web tienen secciones privadas que están protegidas por una contraseña (en Apache tenemos los típicos ficheros .htaccess que protegen directorios del servidor web, por ejemplo). La debilidad de este tipo de protección es que la contraseña viaja por la red en texto plano si no nos aseguramos de usar medios de encriptación como pueda ser una conexión median SSL al puerto 443 del servidor. Las advertencias de los navegadores no son en vano, y no deberían tomarse a la ligera dentro de una LAN en la que pueda haber sniffers de red. Un túnel SSH protegería de forma sencilla que esas contraseñas puedan ser espiadas.
POP3	110	Este protocolo (así como su antecesor POP2 en el puerto 109) es el candidato ideal a ser utilizado mediante un túnel SSH. Casi sin darnos cuenta, nuestros clientes de correo envían constantemente nuestro login y password al servidor de correo para sondear si hemos recibido nuevos mensajes. Todo este tráfico viaja en texto plano, por lo que puede ser capturado, analizado y la confidencialidad de nuestro correo podría verse afectada. Además, es posible que un eventual atacante que se hiciese con un usuario y clave de POP3, consiguiese entrar en servidor con ellos por otro protocolo. Además de esto, POP3 puede ser totalmente reemplazado por scripts que usan de forma nativa SSH, como scpmail, appendmail o loopmail.
NNTP	119	De la misma manera que sucede con POP3, nuestros clientes de noticias también se autentican automáticamente, si bien es cierto que la mayoría de servidores de news permiten acceso anónimo.
SMB	139	Las transferencias de ficheros mediante este protocolo típico de plataformas Microsoft también puede ser un objetivo de los túneles SSH. Existen varios problemas al respecto:  La navegación dentro de directorios compartidos se realiza por UDP, por lo que no podremos realizarla a través del túnel SSH.  NETBIOS siempre utiliza el puerto 139 y no puede ser reemplazado por otro, por lo que necesitaremos privilegios de root para utilizar ese puerto (<1024).  Si queremos utilizar el puerto 139 para un túnel SSH, no podremos compartir ficheros de nuestra máquina al mismo tiempo. Deberemos elegir entre la conexión SSH y la conexión normal.  Por todo ello, quizá convenga utilizar sftp y olvidarse de Samba para intercambios de ficheros.
IMAP	143, 220	IMAP admite el uso de túneles SSH de forma similar a POP3. Sin embargo, algunas de las posibilidades extra que ofrece IMAP con respecto a POP3, como pueda ser la organización de los mensajes en carpetas, pueden verse afectadas si no se utilizan los puertos originales para este protocolo (143 para IMAP2 o IMAP4 y 220 para IMAP3). Por ello, quizá necesitemos tener privilegios de root para hacer el port-forwarding para IMAP.
MySQL	3306	Nuestras conexiones remotas a Bases de Datos pueden también servirse de esta técnica. He elegido MySQL por ser bastante popular entre los programadores de entornos Linux, pero los túneles SSH pueden utilizarse para conectar con los múltiples tipos diferentes de Bases de Datos accesibles desde nuestros sistemas.
RPC (NIS, NFS...)	111	Holger Trapp programó un paquete denominado "sec_rpc" que utilizaba SSH para aumentar la seguridad de los protocolos basados en RPC (Remote Procedure Calls). Actualmente se ha mejorado bastante ese paquete y permite incluso túneles UDP con SSH versión 2. Este tipo de túneles son los que se usan para SNFS (Secure NFS), o NIS, protocolos históricamente inseguros, que se benefician de estos avances y consiguen perder su obsolescencia.
X11	6000	En ocasiones nos preocupamos por la seguridad de nuestras conexiones mediante shells remotas, pero descuidamos la protección de los datos enviados por terminales gráficas. Si usamos SSH tunneling en conexiones X11 evitaremos desagradables sorpresas. Para realizar el tunneling no es necesario fijar la variable de entorno "DISPLAY" de forma manual, el cliente ssh fija su valor automáticamente facilitándonos el proceso.

9.-Conclusión

El SSH Tunneling es una alternativa sencilla al empleo de protocolos de forma insegura, sin tener que hacer modificaciones en el propio protocolo. Además, esta técnica es aplicable a un amplio espectro de escenarios (como hemos podido comprobar) y es altamente escalable. Por todo ello recomiendo su empleo siempre que sea posible.