SSH: Secure Shell

Nuria León García

Unai Martínez Busto
4 de Noviembre de 2004
0. Índice

1.Introducción a SSH 3-6

1.1.¿Qué es SSH? 3

1.2.Protocolo 4

1.3.Historia 5

2.Implementación de SSH 7-11

2.1.SSH “Oficial” 7

2.2.OpenSSH 7

2.3.Alternativas a OpenSSH y SSH Oficial 8

2.4.Dentro de SSH 9

2.5.SSH y otras aplicaciones 10

3.Alternativas a SSH: SSL, S-HTTP y IPsec 12-13

4.Conclusiones 14

Referencias y Bibliografía 15

2
1.Introducción a SSH

En este documento haremos una descripción de los distintos aspectos

que componen SSH. Se hará una breve introducción en la que se describen
los aspectos generales, para continuar con una descripción en profundidad
de los distintos protocolos y algoritmos usados por SSH. Pasaremos en el
apartado 3, enumerar y analizar las distintas opciones de SSH, y por último
se incluirá un apartado de conclusiones.
La fuente principal de información para completar este trabajo ha sido
Internet, encontrándose aquí gran cantidad de información, siendo por lo
tanto fácil contrastar las distintas fuentes. En el apartado de referencias se
muestran las paginas web consultadas.

1.1.¿Qué es SSH?

SSH es un programa de login remoto que nos permite realizar una

transmisión segura de cualquier tipo de datos: passwords, sesión de login,
ficheros, etc, sustituyendo a las habituales formas de acceso (Telnet, FTP…).
Su seguridad reside en el uso de criptografía fuerte, de manera que toda la
comunicación es encriptada y autentificada de forma transparente para el
usuario. [2]
La idea en la que se basa SSH es la de hacer un túnel por el cual
viajarán los datos de manera segura ("tunneling"). 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 para ilustrar el concepto de "tunneling":
cuando viajamos 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

3
están las aplicaciones estándar 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. 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[1]:

Proceso de tunneling SSH.

1.2.Protocolo

El protocolo SSH se establece en tres niveles:

ƒ Nivel de transporte
En este nivel se procede a la autenticación del servidor, el
establecimiento de un canal cifrado, chequeo de integridad de los mensajes,
así como generación de un identificador único de sesión.
En cuanto a los algoritmos empleados se establecen algunos como
requeridos y otros como opcionales. Por nombrar:
o Intercambio de claves : Diffie-Hellman
o Algoritmos de clave pública para encriptación y autenticación
del servidor: DSA, certificados X.509, certificados PGP etc.
o Algoritmos de clave simétrica: 3Des en modo CBC , blowfish,
idea-cbc etc. , todos con claves de 128 bit

4
 o Algoritmos de integridad: HMAC-SHA1 , HMAC-MD5 etc.
ƒ Nivel de autentificación del usuario
En este nivel se supone establecida la encriptación e integridad del
canal, así como la autentificación del servidor.
Para la autentificación del usuario el SSH ofrece varias posibilidades.
La autentificación usando un par de clave pública-privada .
La autentificación del usuario basada en passwords .Hay que señalar
que el password no va encriptado, sino que es el canal por el que va el
password el que si esta encriptado (nivel transporte). Es tarea del servidor la
validación del password en su base de datos correspondiente.
La autentificación del usuario basada en procedencia del host. En esta
situación hay que proteger bien las claves privadas del host por parte del
usuario.
ƒ Nivel de conexión
Es el protocolo encargado de simultanear sesiones interactivas de
login, ejecución remota de comandos, forwarding de conexiones TCP/IP,
forwarding de conexiones X11 etc. [2]

SSH está en vía de convertirse en un protocolo estándar de Internet

por el IETF [11], más conocido por SECSH. Actualmente existen diversos
borradores ("drafts") relacionados que pueden consultarse en [3].

1.3.Historia

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, implantando
una buena política de seguridad, 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 estos problemas tenemos dos alternativas:
1. Elegir protocolos que sean seguros.

5
 2. 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, esto es lo
que se hace con ayuda de 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.
Entonces 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.
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. [1]

6
2.Implementación de SSH

2.1. SSH “Oficial”: SSH Communications Security

SSH Communications Security es el nombre de la empresa que

desarrolla comercialmente los protocolos relacionados con SSH. Tienen una
gran variedad de productos, que van desde clientes a servidores, pasando por
plataformas de seguridad para entornos corporativos. En [6] se ofrece una
amplia información sobre los distintos productos ofertados por esta compañía,
así como informes sobre sus productos y servicios.

2.2. OpenSSH

OpenSSH es una implementación libre del paquete de protocolos

SSH/SecSH que ofrece cifrado para los servicios de red, como por ejemplo
login remoto o transferencia remota de archivos. Se cifra todo el tráfico,
incluidas las contraseñas, para eliminar las escuchas, los secuestros de
conexiones, así como diversos ataques que se producen a nivel de red.
OpenSSH fue desarrollado en primera instancia para el sistema
operativo OpenBSD, integrándolo en la versión OpensBSD 2.6 por primera vez.
En el sistema operativo OpenBSD se encuentran todos los programas del
paquete OpenSSH, haciéndolo un sistema robusto en cuanto a seguridad.
Para el desarrollo de OpenSSH se forman dos grupos, el primero se
encarga de la versión no portable del mismo, desarrollandola para OpenBSD.
Una vez que se concluye con la versión no portable, el otro equipo de
desarrollo hace portable la versión para el resto de sistemas operativos.
Las características principales de SSH se listan a continuación:
o Proyecto de Código Abierto: el código fuente esta disponible a
todos desde la pagina oficial www.openssh.com
o Licencia Libre: se puede usar para cualquier propósito incluso
para uso comercial.

7
 o Cifrado Fuerte (3DES, Blowfish, AES, Arcfour): el cifrado
comienza antes de la autenticación, toda la información va
encriptada.
o Reenvío por X11 (cifra el tráfico de X Window System): permite el
cifrado del tráfico en entornos de X windows remotos.
o Reenvío por Puertos (canales cifrados por protocolos de legado):
se pueden enviar conexiones TCP/IP por un canal cifrado a una
maquina remota. Esta característica permite que aplicaciones
como POP se puedan asegurar.
o Autenticación Fuerte (Clave Pública, Contraseña de un sólo uso y
Autenticación con Kerberos): protege de DNS spoofing, IP
spoofing y Rutas falsas.
o Reenvío por Agente (ingreso único): permite no tener que guardar
las claves de autenticación de RSA o DSA en ninguna maquina
que no sea la del usuario.
o Interoperabilidad (Conforme con las Regulaciones del Protocolo
SSH 1.3, 1.5, y 2.0): puede operar con las diferentes versiones de
SSH.
o Soporte para cliente y servidor de SFTP en los protocolos SSH1 y
SSH2: soporte completo para SFTP.
o Pases de Ticket de Kerberos y AFS: pasa tickets para Kerberos y
AFS a la maquina remota, evitando reintroducir la contraseña.
o Compresión de Datos: mejora los resultados de la comunicación
en redes lentas.

2.3. Alternativas a OpenSSH y SSH Oficial

Existen varias implementaciones de SSH libres para los distintos

sistemas operativos del mercado. A continuación citaremos los principales
clientes para Windows, Linux y MacOS.
Los clientes que se mencionan aquí, son los recomendados en [4] por su
interoperabilidad con OpenSSH.
Windows: PuTTY, TTSSH, MSSH.
Unix: FreeSSH, OSSH, LSH/psst.

8
 MacOS: MacSSH, Fugu.

2.4. Dentro de SSH.

En general, las características descritas anteriormente para OpenSSH

son implementadas por los dos paquetes más conocidos de SSH, con ciertas
salvedades, ya que OpenSSH solo hace uso de algoritmos de libre uso.
Existen dos versiones de SSH: SSH1 y SSH2. SSH1 y SSH2 son
incompatibles entre si. De hecho, son dos protocolos completamente
diferentes. Encriptan diferentes partes de los paquetes. SSH1 usa las claves
del cliente y del servidor para autenticar, mientras que SSH2 solo usa las
claves de la parte cliente. SSH2 es una reescritura completa del protocolo
usado por SSH1, cambiando incluso la implementación a nivel de red,
haciéndolo más portable y seguro. SSH2 es mas seguro que SSH1.
Se pueden añadir o quitar algoritmos en cada nueva implementación de
SSH, lo que le otorga gran capacidad de adaptación y facilidades para el
escalado.
Dependiendo de la versión de SSH se usaran unos algoritmos u otros.
Actualmente el desarrollo de SSH se centra en SSH2, por lo que incluye
algoritmos mas seguro que su predecesor. En la siguiente tabla se muestran
los algoritmos usados por cada versión. El contenido de esta información se
puede hallar en [5]

Algoritmos de encriptación:
Algoritmo SSH1 SSH2
DES Si No
3DES Si Si
IDEA Si No
Blowfish Si Si
Twofish No Si
Arcfour No SI
Cast128-cbc No Si

9
 Se puede observar que SSH2 no incorpora DES ya que es posible
romperlo por fuerza bruta. Tampoco hace uso de IDEA ya que es un algoritmo
patentado en varios países. Blowfish, Twofish son sistemas de cifrado rápido
de bloque. Arcfour es un algoritmo compatible con RC4 de RSA.

Algoritmos para la autenticación:

Algoritmo SSH1 SSH2
RSA Si No*
DSA No Si

* La versión de pago si lo utiliza.

DSA es más moderno que RSA, además soluciona ciertos defectos en
RSA, considerándose mas seguro.

2.5. SSH y otras aplicaciones

SSH en FTP (puerto 21)

o 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 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 SSH.
o Es necesario usar el modo pasivo 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 de SSH (típicamente la propia máquina
servidora) y no con la máquina cliente que realiza la petición.
Debido a estos problemas de seguridad, en la nueva versión de SSH.
SSH2, en conexiones FTP, está siendo reemplazado por conexiones "sftp",
que proporcionan protección tanto de datos como de comandos.

SSH en TELNET (puerto 23)

10
 Realizar conexiones Telnet o rsh mediante SSH no tiene ningún
sentido, ya que SSH es ya el protocolo para shell remota de forma segura.

SSH en SMTP (puerto 25)

Ahora que a consecuencia del spam casi todos los servidores SMTP
tienen unas políticas de "relay" muy severas, SSH en conexiones SMTP
puede aumentar la comodidad de muchos usuarios.

SSH en HTTP (puerto 80)

Muchos servidores web tienen secciones privadas que están

protegidas por una contraseña. 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 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.
SSH protegería de forma sencilla que esas contraseñas puedan ser espiadas.

SSH en POP3 (puerto 110)

Este protocolo es el candidato ideal a ser utilizado mediante 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 y analizado. La confidencialidad de nuestro correo se vería afectada.

11
3. Alternativas a SSH: SSL, S-HTTP e IPsec.

SSH ofrece una solución completa a gran variedad de problemas

relacionados con la seguridad. En este apartado se abordaran diferentes
protocolos utilizados en comunicaciones seguras, tanto generales (caso de
SSL) o especificas para la web (Secure HTTP).
SSL (Secure Sockets Layer) es un protocolo desarrollado por Netscape
[7] en el año 1994, para transmitir documentos privados a través de Internet.
Está basado en la aplicación conjunta de criptografía simétrica, criptografía
asimétrica, certificados digitales y firmas digitales para conseguir un canal o
medio seguro de comunicación a través de Internet. SSL trabaja usando una
clave privada para encriptar los datos que son transmitidos por una conexión
SSL. SSL ejecuta un protocolo de negociación para establecer una conexión
segura a nivel de socket (nombre de la maquina más el puerto), haciendo que
los servicios de seguridad sean transparentes al usuario y a la aplicación.
Su mayor ventaja es que funciona entre la capa TCP y la capa de
aplicación, por esto es muy fácil usarlo para proteger los protocolos de la capa
de aplicación (por ejemplo FTP, gopher, HTTP...) sin tener que realizar
cambios importantes en los mismos. Más concretamente, para asegurar el
protocolo HTTP, surgió HTTPS, que mediante el uso de SSL consigue que la
comunicación en la web sea segura. Sirve para crear un canal cifrado (cuyo
nivel de cifrado depende del servidor remoto y del navegador utilizado por el
cliente) más apropiado para el tráfico de información sensible que el protocolo
HTTP. Es utilizado principalmente por entidades bancarias, tiendas en línea, y
cualquier tipo de servicio que requiera el envío de datos personales o
contraseñas. Actualmente es el estándar de comunicación segura en los
navegadores web más importantes.
Existe numerosa documentación sobre SSL, ya que es usado con
bastante frecuencia. Para más información, sobre los algoritmos de
encriptación que utiliza se puede consultar [8].
En comparación con SSH, podemos decir que ambos protocolos pueden
ser instalados en un mismo servidor, complementándose uno al otro. Su mayor

12
diferencia esta en que SSH cifra todos los canales que utiliza, mientras que
SSL no.
Secure HTTP (S-HTTP), los protocolos S-HTTP están integrados con
HTTP. Aquí, los servicios de seguridad se negocian a través de las cabeceras y
atributos de la página. Por lo tanto, los servicios de S-HTTP están disponibles
sólo para las conexiones de HTTP. Es un protocolo a nivel de aplicación, que
extiende HTTP para hacerlo seguro. Las negociaciones entre el cliente y el
servidor tienen lugar intercambiando datos formateados. Estos datos incluyen
una variedad de opciones de seguridad y algoritmos a utilizar. La lista completa
de los algoritmos utilizados se encuentra en [9].
IPsec (IP Security) [12] son un conjunto de protocolos desarrollados por
la IETF para soportar intercambio de paquetes de forma segura a nivel IP.
Consigue además, al trabajar a nivel IP, seguridad para los niveles superiores.
En un primero momento fue desarrollado para Ipv6, para posteriormente
adaptarlo para Ipv4. IPsec ha sido ampliamente utilizado para la
implementación de VPNs (Virtual Private Networks) [10]. IPsec soporta dos
tipos de encriptado: Transport y Tunnel. El primero, solo se encripta la porción
de datos de cada paquete, dejando las cabeceras intactas. Por su parte el
modo Tunnel, más seguro, cifra tanto los datos como las cabeceras. De esta
forma un datagrama IP se encapsula por completo en un nuevo datagrama
IPsec. La diferencia principal con SSH, radica en el hecho de que IPsec esta
orientado a proteger todo el trafico que circula por la red, pero sin autentificar al
usuario, mientras que SSH identifica tanto al usuario como al servidor. La
elección de uno u otro, se debe basar en un estudio de las necesidades en
cada situación. Es posible incluso utilizar SSH y IPsec de forma conjunta, de
forma que primero se establece un “túnel” IPsec y luego utilizamos SSH para
hacer login con la maquina remota.

13
4. Conclusiones

A través de este documento se han reseñado las características

principales de SSH así como sus usos en comunicaciones seguras. Se han
descrito los protocolos y algoritmos utilizados, así como las diferentes
versiones que existen. A su vez, se han enumerado las distintas
implementaciones existentes, tanto de código libre como comerciales.
Se puede concluir que SSH ofrece suficientes garantías, a través de sus
protocolos, como para poder confiar en él, siendo un sustito robusto para las
aplicaciones existente que trabajan de forma no segura. Su uso para asegurar
otro tipo de aplicaciones (FTP, HTTP, etc.) le otorga gran versatilidad y utilidad.
Por último se han mostrado posibles alternativas al uso de SSH, como
pueden ser SSL o IPSec. De lo expuesto en este documento, remarcar que hoy
por hoy no existe una alternativa a SSH, si no más bien, que entre todos los
protocolos y aplicaciones expuestos, permiten asegurar las comunicaciones a
varios niveles. En la mayoría de los casos, lo ideal es complementar el uso de
SSH con el resto de protocolos disponibles.
Gracias a este documento hemos podido ver con cierta profundidad
aspectos que de otro modo no veríamos, aspectos como por ejemplo los
protocolos usados por SSH o la utilización de SSH con otras aplicaciones, así
como la utilización de otros protocolos de forma conjunta a SSH.

14
5.Referencias y Bibliografía

[1] http://www.txipinet.com/ssh.php
[2] http://www.cica.es/seguridad/SSH/ssh.es.html
[3] ftp://ftp.ietf.org/internet-drafts/draft-ietf-secsh-architecture-06.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-secsh-connect-08.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-secsh-transport-08.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-secsh-userauth-08.txt
[4] http://www.openSSH.com
[5] http://www.ayahuasca.net/ssh/ssh-faq.html
[6] http://www.ssh.com
[7] http://www.netscape.com
http://wp.netscape.com/eng/ssl3/
[8] http://www.htmlweb.net/seguridad/ssl/ssl_5.html
[9] http://www.iec.csic.es/criptonomicon/shttp.html
[10] http://www.vpnc.org/
[11] http://www.ietf.org
[12] http://www.ietf.org/html.charters/ipsec-charter.html

15