Universidad de Buenos Aires Secure Shell (SSH)

Universidad de Buenos Aires
Facultad de Ingenierı́a
Seminario de Redes de Computadoras
Secure Shell (SSH)
Monografı́a
Alumnos:
Melisa Halsband
Sergio Mujica
Profesores:
Ing. Marcelo Utard
Ing. Pablo Ronco
2o cuatrimestre de 2008
Índice general
1. Introducción
1.1. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Implementaciones . . . . . . . . . . . . . . . . . . . . . . . . .
1.3. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
3
4
4
2. Convenciones y Nomenclatura
2.1. Tipos de Dato . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2. Números de Mensaje . . . . . . . . . . . . . . . . . . . . . . .
2.3. Nomenclatura de Algoritmos . . . . . . . . . . . . . . . . . . .
6
6
6
6
3. Protocolo de Transporte
3.1. Formato de los Mensajes . . . . . . . . . . . .
3.2. Protocolo de los Paquetes Binarios . . . . . .
3.2.1. Compresión y Encriptación . . . . . .
3.2.2. Integridad de los Datos . . . . . . . . .
3.3. Intercambio de Claves . . . . . . . . . . . . .
3.3.1. Descripción del Intercambio de Claves
3.3.2. Resultado del intercambio de claves . .
3.3.3. Petición de Servicio . . . . . . . . . . .
3.4. Consideraciones de Seguridad y Análisis . . .
4. Protocolo de Autenticación
4.1. Proceso de Autenticación del Cliente . . .
4.2. Formato de los Mensajes . . . . . . . . . .
4.3. Métodos de Autenticación . . . . . . . . .
4.3.1. Autenticación por Clave Pública . .
4.3.2. Autenticación por Contraseña . . .
4.3.3. Autenticación Basada en el Origen
4.4. Consideraciones de Seguridad . . . . . . .
4.4.1. Fallas en la Capa de Transporte . .
4.4.2. Mensajes de Depuración . . . . . .
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
11
12
13
14
14
15
16
17
17
.
.
.
.
.
.
.
.
.
18
18
19
20
20
20
21
21
21
21
4.4.3. Nombres de Usuario Inexistentes
4.4.4. Polı́ticas de Seguridad Locales . .
4.4.5. Métodos de Autenticación . . . .
4.5. Análisis . . . . . . . . . . . . . . . . . .
.
.
.
.
5. Protocolo de Conexión
5.1. Canales . . . . . . . . . . . . . . . . . . .
5.1.1. Apertura de un canal . . . . . . . .
5.2. Servicios . . . . . . . . . . . . . . . . . . .
5.2.1. Sesiones Interactivas . . . . . . . .
5.2.2. Redirección de puertos TCP / IP .
5.3. Mensajes . . . . . . . . . . . . . . . . . . .
5.3.1. Sumario de Mensajes . . . . . . . .
5.3.2. Detalle del formato de los mensajes
5.4. Consideraciones de Seguridad . . . . . . .
5.5. Análisis . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
21
22
22
23
.
.
.
.
.
.
.
.
.
.
24
24
25
25
25
27
29
29
29
30
31
6. Conclusiones
32
6.1. Caracterı́sticas de Uso . . . . . . . . . . . . . . . . . . . . . . 32
6.2. Caracterı́sticas de Seguridad . . . . . . . . . . . . . . . . . . . 33
6.3. Conclusión General . . . . . . . . . . . . . . . . . . . . . . . . 33
7. Ejemplos
7.1. Sesiones Interactivas . . . . . . . . . . .
7.1.1. Sesión de Lı́nea de comandos . .
7.1.2. Sesión de redirección de X11 . . .
7.2. Redirección de Puertos TCP/IP . . . . .
7.2.1. Túnel local o saliente . . . . . . .
7.2.2. Túnel remoto, entrante o inverso
8. Referencias
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
35
35
35
36
36
36
37
2
Capı́tulo 1
Introducción
SSH o Secure Shell es un protocolo de red que permite el intercambio
de datos entre dos individuos de la misma red utilizando un canal seguro.
Por canal seguro se entiende una conexión cuyo contenido puede ser accedido
únicamente por las partes involucradas en la conexión (el servidor y el cliente), aunque viaje a través de una red insegura, como por ejemplo Internet.
SSH se vale de los principios de la encriptación simétrica para garantizar la
confidencialidad y la integridad de los datos.
SSH es utilizado con frecuencia en sistemas de tipo UNIX para acceder a
interfaces de lı́nea de comandos (por ejemplo, para tareas de administración).
Tı́picamente, la conexión consiste en el acceso al servidor y la ejecución de
comandos en el equipo remoto, pero SSH también provee la posibilidad de
crear túneles, redirección de puertos TCP, acceso a programas de entorno
gráfico X11 y permite la transferencia de archivos mediante los protocolos
asociados SFTP y SCP; es posible incluso utilizar ssh para montar un sistema
de archivos remoto en forma segura (sshfs).
La arquitectura de SSH es tipo cliente-servidor. El servidor debe tener
ejecutándose, tı́picamente como demonio, un servidor de SSH que mantenga
abierto, y esperando conexiones, en un puerto TCP (por omisión, el 22).
1.1.
Historia
SSH fue creado en 1995 por investigadores de la Universidad de Helsinki, con el propósito de proveer un reemplazo de TELNET que garantizara
autenticación fuerte y confidencialidad de datos.
En 1996, se mejora el protocolo introduciendo SSH-2, una versión revisada incompatible con SSH-1. Se agregan mejoras de seguridad como el intercambio de claves por Diffie-Hellman, comprobación de integridad a través
3
de códigos de autenticación de mensajes y la capacidad de correr cualquier
número de sesiones de lı́nea de comandos sobre una única conexión SSH.
Desde 1999 existe OpenSSH, una implementación de código abierto del
protocolo y la más utilizada en la actualidad. En 2006 SSH fue propuesto
como Estándar de Internet por la Internet Engineering Task Force (IETF).
1.2.
Implementaciones
Existen decenas de implementaciones del protocolo para las plataformas
más comunes con distintas licencias. A continuación listamos algunas:
OpenSSH: La implementación más usada, disponible para más de 10 plataformas. Probablemente la más estable y completa, soporta todos los
métodos de autenticación única e implementa todas las funcionalidades descriptas en el estándar. Su licencia es GPL, es decir es de código
abierto.
PuTTY: Otro cliente bastante conocido, que implementa además otros protocolos además de SSH. Con licencia MIT, también de código abierto.
Dropbear: Implementación optimizada para ser utilizada en dispositivos
con bajos recursos y embebidos. Su licencia también es MIT.
Webbased SSH Client: Cliente Web de SSH. No permite sistemas de autenticación única ni implementa ningún tipo de túneles. Licencia tipo
Freeware y código cerrado.
TouchTerm : Implementación para dispositivos tipo iPhone. No implementa túneles ni provee autenticación única. Desarrollo comercial con licencia privativa.
1.3.
Arquitectura
El protocolo SSH-2 tiene una arquitectura dividida en tres capas, con
funcionamiento general descripto en el RFC 4251 ”The Secure Shell (SSH)
Protocol Architecture”. Estas tres capas son:
Capa de Transporte: La capa de transporte es descripta en el RFC 4253
”The Secure Shell (SSH) Transport Layer Protocol”, y se establece
normalmente sobre una conexión TCP/IP. Se ocupa del intercambio
de claves inicial y autenticación del servidor, y comienza la encriptación, verificación de identidad, y opcionalmente compresión de los
4
datos transmitidos. Esta capa expone a la siguiente una interfaz para
enviar y recibir paquetes de hasta 32 kB en texto plano. Además, fija
un perı́odo (1 hora) o volumen máximo (1 GB) de datos transmitidos
para la renegociación de las claves.
Capa de Autenticación: La capa de autenticación se ubica sobre la capa
de transporte. Provee autenticación del cliente a través de diferentes
métodos. El servidor ofrece una lista de métodos de autenticación soportados, y es el cliente el que decide cuál llevar a cabo. Los métodos
soportados y las combinaciones necesarias para autenticarse con cada servidor dependerán de la configuración de los mismos. Algunos
métodos de autenticación utilizados son el acceso de una contraseña,
la comprobación de una firma con una clave pública, la interacción
con el servidor a través del teclado, o métodos más sofisticados para
autenticación por única vez dentro de una red con un servicio como
Kerberos.
Capa de Conexión: La capa de conexión se ubica sobre las dos anteriores
y se ocupa del funcionamiento y manejo de canales de acuerdo a los
servicios provistos. En ella se multiplexa el canal encriptado en distintos canales lógicos, posibilitando la apertura de múltiples canales,
con transferencia de datos bidireccionales simultáneamente dentro de
la misma conexión SSH.
Al comienzo de la conexión se realizan dos pedidos de servicios: uno al
establecer la capa de transporte segura y otro después de la autenticación del
cliente. Esto tiene el propósito de brindar flexibilidad al sistema, permitiendo
la extensión mediante protocolos adicionales o en reemplazo de las capas ya
descriptas.
5
Capı́tulo 2
Convenciones y Nomenclatura
En esta sección se establecerán las convenciones utilizadas en el resto del
documento.
2.1.
Tipos de Dato
Los tipos de datos, su tamaño en bits y las particularidades de cada uno
se pueden ver en el Cuadro 2.1.
2.2.
Números de Mensaje
El protocolo de SSH se implementa a través de mensajes con números
entre 1 y 255. En el Cuadro 2.2 ilustramos las asignaciones de estos códigos
a los tipos de mensaje.
2.3.
Nomenclatura de Algoritmos
El estándar lista un conjunto de algoritmos de encriptación, integridad
de datos, clave pública/privada y compresión, que se requiere o se sugiere
que sean implementados y permiten extensiones. En el cuadro 2.3 se pueden
encontrar los mismos según su categorı́a, nombre de identificación y grado
de requerimiento en las implementaciones.
6
Tipo
byte
Tamaño
8
boolean
8
uint32
32
uint64
64
string
variable
mpint
variable
name-list
variable
Comentarios
Puede agruparse en arreglos (arrays) de tipo
byte[n]
Aunque representa un valor binario, se representa
con 8 bits. El valor 0 representa FALSO y cualquier
otro valor representa VERDADERO, aunque sólo los
valores 0 y 1 deberı́an almacenarse.
Representa un entero sin signo de 32 bits, almacenado como 4 bytes de significativiad descendiente.
Representa un entero sin signo de 64 bits, almacenado como 8 bytes de significativiad descendiente.
Es una cadena binaria de longitud arbitraria. Se
almacenan como un entero tipo uint32 que contiene la longitud de la cadena n, seguido por n
bytes con el contenido de la misma.
Enteros precisión arbitraria en complemento al
módulo 2, con sus valores representados en un
string binario, con significatividad decreciente.
El signo se representa mediante el bit más significativo.
Es un string con codificación ASCII que contiene nombres separados por comas. Los nombres
deben ser de longitud mayor a cero y no pueden
contener comas.
Cuadro 2.1: Tipos de datos utilizados, tamaños y especificación
7
Protocolo
1 a 19
20 a 29
30 a 49
de Transporte
Mensajes genéricos de la capa de transporte
Negociación de algoritmos
Métodos de intercambios de claves (reutilizados por los
distintos métodos de autenticación)
Protocolo de Autenticación
50 a 59
Mensajes genéricos de autenticación del usuario
60 a 79
Mensajes especı́ficos de cada método de autenticación
(reutilizados por cada método)
Protocolo de Conexión
80 a 89
Mensajes genéricos del protocolo de conexión
90 a 127 Mensajes relacionados a los canales
Reservados para Protocolos del Cliente
128 a 191 Reservados
Extensiones Locales
192 a 255 Mensajes reservados para extensiones locales
Cuadro 2.2: Asignación de números de mensaje
Algoritmo
3des-cbc
blowfish-cbc
twofish256-cbc
twofish-cbc
twofish192-cbc
twofish128-cbc
aes256-cbc
aes192-cbc
aes128-cbc
serpent256-cbc
serpent192-cbc
serpent128-cbc
arcfour
idea-cbc
cast128-cbc
Prioridad
Descripción
Algoritmos de Encriptación
Obligatorio
3DES de tres claves con CBC
Optativo
Blowfish con CBC
Optativo
Twofish de 256 bits con CBC
Optativo
Twofish de 256 bits con CBC
(nombre mantenido por razones históricas)
Optativo
Twofish de 192 bits con CBC
Optativo
Twofish de 128 bits con CBC
Optativo
AES de 256 bits con CBC
Optativo
AES de 192 bits con CBC
Recomendado
AES de 128 bits con CBC
Optativo
Serpent de 256 bits con CBC
Optativo
Serpent de 192 bits con CBC
Optativo
Serpent de 128 bits con CBC
Optativo
Cifrado de flujos ARCFOUR
de 128 bits
Optativo
IDEA con CBC
Optativo
CAST de 128 bits con CBC
8
Algoritmo
Prioridad
Descripción
none
No recomendado Sin encriptación
Algoritmos de Autenticación de Mensajes (MAC)
hmac-sha1
Obligatorio
HMAC-SHA1 de 20 bytes,
con clave de 20 bytes
hmac-sha1-96
Recomendado
Primeros 96 bits de HMACSHA1 de 12 bytes, con clave
de 20 bytes
hmac-md5
Optativo
HMAC-MD5 de 10 bytes, con
clave de 16 bytes
hmac-md5-96
Optativo
Primeros 96 bits de HMACMD5 de 12 bytes, con clave
de 16 bytes
none
No recomendado Sin autenticación
Formatos de Clave Pública y Certificados para Firmas
ssh-dss
Obligatorio
Clave DSS plana
ssh-rsa
Recomendado
Clave RSA plana
pgp-sign-rsa
Optativo
Certificados OpenPGP con
clave RSA
pgp-sign-dss
Optativo
Certificados OpenPGP con
clave DSS
Algoritmos de Intercambio de Claves
diffie-hellman-group1-sha1
Obligatorio
Definido en el RFC 2409 sobre el Intercambio de Claves
en Internet (IKE)
diffie-hellman-group14-sha1 Obligatorio
Definido en el RFC 3526 sobre el Intercambio de Claves
en Internet (IKE)
Algoritmos de Compresión
none
Obligatorio
Sin compresión
zlib
Optativo
Compresión provista por la
ZLIB, descripta en los RFCs
1950 y 1951
Cuadro 2.3: Nombres registrados de Algoritmos
9
Capı́tulo 3
Protocolo de Transporte
El protocolo de capa de transporte provee autenticación del servidor,
confidencialidad e integridad. Opcionalmente puede proveer compresión. Proporciona una negociación inicial de algoritmos (todavia sin cifrar) y luego un
intercambio de claves que acaba con autenticación por parte del servidor y
una conexión criptográficamente segura.
El papel principal de la capa de transporte es facilitar una comunicación
segura entre los dos hosts durante la autenticación y la siguiente comunicación. La capa de transporte lleva a cabo esto manejando la encriptación
y decodificación de datos y proporcionando protección de integridad de los
paquetes de datos mientras son enviados y recibidos. Además, la capa de
transporte proporciona compresión de datos, lo que acelera la transmisión de
información.
Al contactar un cliente a un servidor por medio del protocolo SSH, se negocian varios puntos importantes para que ambos sistemas puedan construir
la capa de transporte correctamente. Durante el intercambio se producen
los siguientes pasos: Intercambio de claves, se determina el algoritmo de encriptación de la clave pública, se determina el algoritmo de la encriptación
simétrica, se determina el algoritmo autenticación de mensajes, y se determina el algoritmo de hash que hay que usar.
El servidor se identifica ante el cliente con una clave de host única durante el intercambio de claves. Obviamente si este cliente nunca se habı́a
comunicado antes con este determinado servidor, la clave del servidor le
resultará desconocida al cliente y no lo conectará. El protocolo evita este
problema permitiendo la opción de que el cliente acepte la clave del host del
servidor después que el usuario es notificado y verifica la aceptación de la
nueva clave del host. Para las conexiones posteriores, la clave del host del
servidor se puede verificar con la versión guardada en el cliente, proporcionando la confianza de que el cliente se está realmente comunicando con el
10
servidor deseado. Si en el futuro, la clave del host ya no coincide, el usuario
debe eliminar la versión guardada antes de que una conexión pueda ocurrir.
Un agresor podrı́a enmascararse como servidor SSH durante el contacto
inicial ya que el sistema local no conoce la diferencia entre el servidor en
cuestión y el falso configurado por un agresor. Para evitar que esto ocurra,
deberı́a verificar la integridad del nuevo servidor SSH contactando con el
adiministrador del servidor antes de conectarse por primera vez o en el evento
en el que no coincidan las claves.
SSH fue ideado para funcionar con casi cualquier tipo de algoritmo de
clave pública o formato de codificación. Después del intercambio de claves
inicial se crea un valor hash usado para el intercambio y un valor compartido secreto, los dos sistemas empiezan inmediatamente a calcular claves y
algoritmos nuevos para proteger la autenticación y los datos que se enviarán
a través de la conexión en el futuro.
Después que una cierta cantidad de datos haya sido transmitida con un
determinado algoritmo y clave (la cantidad exacta depende de la implementación de SSH), ocurre otro intercambio de claves, el cual genera otro conjunto
de valores de hash y un nuevo valor secreto compartido. De esta manera
aunque un agresor lograse determinar los valores de hash y de secreto compartido, esta información sólo será válida por un perı́odo de tiempo limitado.
3.1.
Formato de los Mensajes
Identificador
Número
SSH MSG DISCONNECT
1
SSH MSG IGNORE
2
3
SSH MSG UNIMPLEMENTED
SSH MSG DEBUG
4
SSH MSG SERVICE REQUEST
5
SSH MSG SERVICE ACCEPT
6
SSH MSG KEXINIT
20
21
SSH MSG NEWKEYS
Descripción
Desconexión
Ignorar el mensaje de datos
No implementados
Depuración
Solicitud de servicio
Aceptación del servicio
Negociación de algoritmos
Nuevas claves
Mensaje de depuración
byte SSH_MSG_DEBUG
boolean Mostrar siempre
String mensaje (norma ISO-10646 codificación UTF-8)
String etiqueta de idioma
11
Mensaje no implementado
byte SSH_MSG_UNIMPLEMENTED
uint32 Número de secuencia del paquete del mensaje rechazado
Solicitud de servicio
byte SSH_MSG_SERVICE_REQUEST
String nombre de servicio
Aceptación del servicio
byte SSH_MSG_SERVICE_ACCEPT
String de nombre de servicio
Negociacion de algoritmos
byte SSH_MSG_KEXINIT
byte[16] cookie (bytes aleatorios)
name-list algoritmos de intercambio de claves
name-list algoritmos soportados por el server anfitrión
name-list algoritmos de encriptación simétrica cliente/servidor
name-list algoritmos de encriptación simétrica servidor/cliente
name-list algoritmos MAC cliente/servidor
name-list algoritmos MAC servidor/cliente
name-list algoritmos de compresión cliente/servidor
name-list algoritmos de compresión servidor/cliente
name-list etiquetas de lenguaje cliente/servidor
name-list etiquetas de lenguaje servidor/cliente
boolean sigue primer intercambio de paquetes
uint32 0 reservado para extensiones futuras
Nuevas claves
byte SSH_MSG_NEWKEYS
3.2.
Protocolo de los Paquetes Binarios
SSH trabaja sobre una capa de transporte binaria y transparente de 8
bits. Cada paquete tiene el siguiente formato:
12
uint32 packet_length
byte padding_length
byte[n1] payload; n1 = packet_length - padding_length - 1
byte[n2] random padding; n2 = padding_length
byte[m] mac(Message Authentication Code);m=mac_length
packet length: Longitud del paquete (bytes), sin incluir MAC.
padding length: Longitud del relleno (bytes)
payload: El contenido útil del paquete. En caso de haber sido negociado
compresión,este campo es comprimido. Por default la compresión es
nula.
padding: Se realiza un relleno arbitrario tal que la longitud total de los
campos nombrados anteriormente, sea un múltiplo del tamaño del bloque de cifrado. Tiene que al menos existir 4 bytes de relleno, siendo el
máximo 255 bytes. Dicho relleno pueden ser bytes aleatorios.
mac: Código de autenticación de mensaje. El tamaño mı́nimo del paquete
es 16 bytes, y el tamaño máximo del paquete debe poder enviar 32768
bytes de datos sin comprimir, con un tamaño total del paquete de 35000
bytes. Las implementaciones deberı́an de soportar paquetes mayores
para tareas especı́ficas.
3.2.1.
Compresión y Encriptación
Si se negoció compresión, solo el campo con carga útil es el que se comprime, usando el algoritmo convenido, por ejemplo el zlib. Los campos packet length
y mac serán calculados a partir del payload comprimido, y la encriptación
se hará luego de la compresión.
Un algoritmo de encriptación y una clave son negociados durante el intercambio de claves. Cuando éste tiene efecto, los packet length, padding length
y payload de cada paquete deben ser encriptados con el algoritmo convenido. Todos los cifradores deben usar claves con una longitud efectiva igual o
mayor de 128 bits.
Pueden encontrarse los algoritmos de cifrado de los mensajes en el cuadro
2.3. La opción de no usar encriptación sólo debe ser usada para depuración.
En algunos casos, tal como en el uso de encriptación simétrico (ej: DES),
las partes que desean comunicarse o autenticarse, deben conocer la misma
clave secreta. La misma clave, también conocida como una clave secreta usada
para conducir tanto la encriptación la desencriptación del mensaje. Puede ser
13
extremadamente eficiente, requiriendo mı́nimo de procesamiento ya sea para
encriptar o desencriptar el mensaje. El problema es que tanto el que envı́a
como el que recibe deber conocer la clave de encriptación. Si por alguna razón
la copia de la clave es comprometida, un intermediario puede desencriptar y
leer los mensajes.
En los casos de encriptación asimétrica o de clave pública (ej: RSA), las
claves se producen de a pares. Una es la privada, secreta para una de las
partes, y otra es la pública, la cuál es publicada para todo el mundo. La
clave puede ser usada ya sea para encriptar o desencriptar el mensaje, sin
embargo, si la clave A es usada para encriptar el mensaje, solo la clave B
puede desencriptarla, y si la clave B es usada para encriptar un mensaje,
solo la clave A puede desencriptarlo. La clave pública es almacenada en un
lugar publico, donde cualquiera puede usarla. La clave privada es un secreto
conocido solo por el dueño del par de claves.
Es computacionalmente imposible hallar la clave privada mediante la
pública. En la mayorı́a de los casos, un adversario podrı́a intentar determinar
la clave secreta por el método simple de prueba y error. La probabilidad que
éste tenga éxito es muy baja en general.
3.2.2.
Integridad de los Datos
La integridad de los datos es protegida incluyendo en cada paquete un
código de autenticación de mensaje (MAC), que es computado desde el contenido del paquete y un número de secuencia del mismo. El algoritmo MAC
es negociado durante el intercambio de claves. Pueden encontrarse los algoritmos de autenticación de los mensajes en el cuadro 2.3.
El protocolo acepta distintos tipos de algoritmos de clave pública. Entre
ellos se encuentra el DSS (Digital Signature Standard) y certificados SKIP,
CA, PGP y X509.
3.3.
Intercambio de Claves
Los métodos de intercambiod de claves especifican cómo se generan las
claves de sesión, y cómo se autentica el servidor. El único algoritmo obligatorio es el Diffie-Hellman.
Intercambio exponencial DIFFIE-HELLMAN: Primer algoritmo
de clave pública, enunciado por W. Diffie y M. Hellman en 1976, que basa
su seguridad en la dificultad de calcular logaritmos discretos en un cuerpo
finito. Se emplea para distribución de claves pero no para cifrar y descifrar.
14
Tras ponerse de acuerdo sobre las versiones y otros detalles similares, tiene
lugar un intercambio de claves tipo Diffie-Hellman. Matemáticamente esto
permite que dos partes deriven un secreto compartido comunicándose a través
de un canal inseguro sin que un hipotético pinchazo en la conexión permita
averiguar ese secreto. En el proceso se usan las claves públicas/privadas, y
existe la posibilidad de que se produzca un ataque de tipo man-in-the-middle.
El secreto compartido que derivan ambas partes, cliente y servidor, es
una clave para un algoritmo simétrico (mucho menos costoso que los de
asimétricos o de clave pública/privada) que es lo que se usa realmente para
cifrar la comunicación en ambos sentidos. En esta etapa además se verifica
mediante firmas la identidad del servidor, para asegurar que no lo están
suplantando.
Algoritmos de clave pública: El algoritmo requerido por toda implementación es el algoritmo DSS, aunque pueden implementarse muchos más.
El tipo de clave debe conocerse de antemano (por ejemplo, especificándolo
en la negociación del algoritmo).
3.3.1.
Descripción del Intercambio de Claves
Cada equipo envı́a una lista de los algoritmos que soporta. Cada una de
las partes tiene un algoritmo preferido para cada una de las categorı́as, y
se presupone que la mayorı́a de las implementaciones van a usar siempre el
mismo algoritmo preferido. Cada parte puede suponer qué algoritmo está utilizando el otro equipo, y puede enviar un paquete de intercambio de claves
según ese algoritmo si corresponde con el algoritmo predefinido.
Esta suposición es incorrecta si: El algoritmo de intercambio y/o el algoritmo de clave de equipo se presuponen de manera incorrecta (el algoritmo
predefinido es distinto en el cliente y en el servidor), o si pueden ponerse de
acuerdo en cualquiera de los otros algoritmos. En caso contrario, la suposición se considera correcta, y el primer paquete enviado debe de ser gestionado
como el primer paquete de intercambio de claves.
De todos modos, si la suposición es incorrecta, y se ha enviado algún
paquete de intercambio de claves, estos paquetes serán ignorados, y el lado
implicado deberá de enviar un paquete de inicio correcto.
La autenticación del servidor en el intercambio de claves puede ir implı́cita. Tras un intercambio de claves con autenticación implı́cita, el cliente debe
esperar una respuesta a su petición de servicio antes de enviar más datos.
El primer algoritmo de cada lista debe de ser el preferido por la parte (el
que se presupondrá), y ninguna lista de algoritmos puede ser vacı́a.
Si ambas partes tienen el mismo algoritmo de intercambio de clave, se
utilizará ese algoritmo. En caso contrario, se seguirá el siguiente algoritmo,
15
iterando sobre los algoritmos soportados por el cliente. Se elegirá el primero
que: esté soportado por el servidor; si necesita cifrado, hay un algoritmo de
cifrado de clave de host (clave del equipo servidor) en el servidor que también
está soportada en el cliente; si necesita una clave del equipo servidor con
firma, este algoritmo de firma existe en el servidor, y en el cliente; si ningún
algoritmo satisface estas condiciones, ambos lados deben desconectarse.
Tras el envı́o de este paquete, se produce el intercambio de claves según
el algoritmo escogido.
3.3.2.
Resultado del intercambio de claves
Este intercambio produce dos valores: una clave secreta K, y un valor de
intercambio H. El valor H del primer intercambio de claves es también el
identificativo de sesión, y se genera a partir de una función de HASH.
Uso de las claves
El intercambio de claves termina con el envı́o de un comando SSH MSG NEWKEYS.
Este mensaje se envı́a utilizando las claves y algoritmos que se utilizaban hasta ese momento, y tras su envı́o, todos los demás paquetes que se envı́en lo
harán con estas nuevas claves y algoritmos.
Cuando este mensaje se recibe, los nuevos algoritmos y claves deberán
utilizarse para recibir los siguientes paquetes.
Tras el intercambio de claves, éste es el único paquete válido (junto con la
orden de desconexión, el paquete “ignore” y el paquete “debug”), para que
ambos equipos confirmen que todo ha ido bien.
En el caso del intercambio de claves Diffie-Hellman, se calcula una clave
secreta, compartida por ambos equipos, que no puede determinarse sino es
por colaboración de ambos. El intercambio de claves se combina con una
firma utilizando la clave del host del servidor para autenticar a éste.
Re-intercambio de claves
Si se recibe un mensaje de intercambio de claves (y no se está realizando
ya uno), ambas partes vuelven a negociar la clave.
Este intercambio se realiza utilizando el cifrado activo en ese momento.
Los métodos de cifrado, compresión y MAC no se cambian hasta que termine
la negociación, y se procesa de manera idéntica al intercambio inicial (excepto
que el identificador de sesión no cambia).
Se recomienda cambiar las claves después de la transferencia de un gigabyte, o una hora de conexión.
16
Tras el intercambio se puede continuar enviado datos.
3.3.3.
Petición de Servicio
Tras el intercambio inicial de claves, el cliente solicita un servicio, identificado por un nombre, usando el mensaje SSH MSG SERVICE REQUEST.
Los servicios inicialmente implementados son el de autenticación y el de petición de conexión.
Si el servidor no acepta la petición, deberá desconectarse, y si lo acepta,
deberá notificarlo al cliente.
El servicio puede tener acceso al identificador de sesión generado en el
intercambio de claves.
3.4.
Consideraciones de Seguridad y Análisis
Este protocolo proporciona un canal cifrado seguro en una red insegura.
Realiza autenticación del servidor anfitrión, intercambio de claves, encriptación, y protección de integridad. Esto provee también una única identificación
de sesión que puede ser utilizada por los protocolos de más alto nivel para
enlazar datos en un determinado perı́odo de sesiones y evitar la repetición
de los datos de anteriores perı́odos de sesiones.
El protocolo permite plena negociación de encriptación, integridad, intercambio de claves, y de requerirlo, compresión, y algoritmos de clave pública
y formatos. Los algoritmos pueden ser diferentes para cada sentido.
17
Capı́tulo 4
Protocolo de Autenticación
La autenticación del cliente en una conexión SSH se hace según el Protocolo de Autenticación. La autenticación se llevará a cabo una vez completada
la fase de transporte, que proveerá a la siguiente capa de confidencialidad (encriptación), autenticación del servidor, y un identificador único de sesión; y
deberá finalizarse antes de empezar la conexión.
4.1.
Proceso de Autenticación del Cliente
La autenticación del cliente es dirigida desde el servidor. Éste puede proveer al cliente de una variedad de métodos de autenticación para otorgarle
más flexibilidad, o bien puede forzarlo a utilizar un conjunto restringido de
éstos. Los métodos de autenticación se obtienen del servidor por medio de
una petición de autenticar, a través de un mensaje que envı́a el cliente. Al
recibir un pedido de autenticación, el servidor responderá el mismo con un
mensaje de éxito o bien con uno de falla.
El pedido de autenticación debe incluir el nombre de usuario en el servidor
que se solicita autenticar, el servicio solicitado, el método de autenticación y
los datos necesarios para autenticar con ese método. Por lo tanto, el cliente
debe proveer todos los datos de la autenticación juntos y debe incluir en el
pedido además el servicio que se utilizará. Por otro lado, se da al cliente la
posibilidad de elegir el método de autenticación que desee mientras esté soportado por el servidor.
El mensaje de éxito en la autenticación se enviará recién cuando el proceso
haya terminado, por lo que es posible que el servidor responda con un mensaje
de falla aunque el método elegido de autenticación funcione adecuadamente.
Esto se debe a que el servidor puede requerir una conjunción de métodos
para autenticar y no sólamente uno. Para informar al cliente que el método
18
ha funcionado, existe un campo en el mensaje de falla que indica éxito parcial
del método de autenticación solicitado.
El mensaje de falla lista además los métodos de autenticación que todavı́a se permiten en la conexión vigente, de los que el cliente puede elegir
nuevamente.
Además, es posible que el servidor envı́e un mensaje de aviso al cliente
para que éste sea mostrado en pantalla, para informar que la autenticación
se llevará a cabo con ese servidor.
4.2.
Formato de los Mensajes
Los mensajes generales del protocolo de autenticación y sus números de
identificación son:
Identificador
SSH MSG USERAUTH
SSH MSG USERAUTH
SSH MSG USERAUTH
SSH MSG USERAUTH
Número
REQUEST
50
FAILURE
51
SUCCESS
52
BANNER
53
Descripción
Pedido de autenticación
Falla en la autenticación
Éxito en la autenticación
Aviso de autenticación
Estos mensajes tienen el siguiente formato:
Pedido de autenticación
Tipo
Información
byte
Número de mensaje (50)
string
Nombre de usuario en codificación UTF-8
string
Servicio solicitado en codificación ASCII
string
Método de autenticación en codificación ASCII
variable
Campos especı́ficos del método de autenticación
Falla en la autenticación
Tipo
Información
byte
Número de mensaje (51)
name-list Métodos de autenticación que se pueden seguir intentando
boolean
Éxito parcial
Éxito en la autenticación
Tipo
Información
byte
Número de mensaje (52)
19
Aviso de
Tipo
byte
string
string
4.3.
autenticación
Información
Número de mensaje (53)
Mensaje en codificación UTF-8
Identificador de idioma
Métodos de Autenticación
Los métodos de autenticación que pueden figurar en las listas de métodos
permitidos y en los campos de método de los mensajes son los siguientes:
Identificador
publickey
password
hostbased
none
4.3.1.
Prioridad
Obligatorio
Optativo
Optativo
No recomendado
Descripción
Clave pública
Contraseña
Basado en el Origen
Sin autenticación
Autenticación por Clave Pública
Este método de autenticación es el único requerido por la especificación y
consiste en el reconocimiento del cliente por medio de una clave pública que
está almacenada en el servidor. El servidor reconoce la identidad del cliente
a través de la firma de un paquete de datos con su clave privada, almacenada
en el cliente.
El paquete de datos que el cliente debe firmar para asegurar su identidad incluye todos los datos del mensaje del pedido, la clave pública, y el
identificador de sesión.
4.3.2.
Autenticación por Contraseña
Este método de autenticación envı́a una contraseña al servidor que el
mismo deberá reconocer. La contraseña se envı́a en texto plano, por lo que
es crı́tico para el uso de este método contar con una encriptación apropiada
provista por la capa anterior.
La contraseña deberá ser enviada en codificación UTF-8, lo que debe ser
tenido en cuenta en sistemas que utilicen otro tipo de codificación.
En caso de registrarse una contraseña que expiró, no debe permitirse el
acceso. Sin embargo, es posible mediante un intercambio de mensajes especı́ficos del método, realizar una actualización de la contraseña.
20
4.3.3.
Autenticación Basada en el Origen
La autenticación basada en el origen puede resultar muy práctica para
redes privadas. Consiste en la autenticación del usuario según el equipo de
origen del que venga el pedido. En este caso, la autenticación se efectúa
sólamente conociendo el nombre de usuario de la cuenta en el servidor y la
clave pública del equipo en el que se corre el cliente.
De esta manera, es el equipo en el que corre el cliente el que garantiza la
identidad del usuario, basándose en sus propios métodos de autenticación, y
el servidor confı́a en la integridad del cliente.
4.4.
Consideraciones de Seguridad
La seguridad de la capa de autenticación depende en gran medida de
la provista por la capa de transporte (la autenticación del servidor, la encriptación del canal de comunicación, y la existencia de un identificador de
sesión). Por otro lado, distintos aspectos de la integridad del servidor y del
cliente son requeridos para garantizar la seguridad de distintos métodos de
autenticación.
4.4.1.
Fallas en la Capa de Transporte
Si la capa de transporte no provee encriptación (lo suficientemente robusta), todos los datos provistos durante la etapa de autenticación estarán disponibles para cualquier observador de la comunicación. Esto puede publicar
nombres de usuario y claves si el método de autenticación es por contraseña,
o simplemente además de exponer toda la comunicación que se llevará a cabo
en adelante.
4.4.2.
Mensajes de Depuración
Los mensajes de depuración del servidor SSH pueden suministrar mucha
información acerca del estado de la autenticación y opciones de configuración
del mismo. Se recomienda, entonces, para evitar vulnerabilidades, mantenerlos deshabilitados a menos que se requiera explı́citamente dicha información.
4.4.3.
Nombres de Usuario Inexistentes
En caso de hacerse una solicitud de autenticación que incluya un nombre
de usuario que no posee cuenta en el servidor, se puede responder de distintas
formas: la rección natural deberı́a ser desconectarse inmediatamente, pero
21
este comportamiento darı́a información acerca de las cuentas que sı́ existen en
el servidor, por lo que otra opción sugerida es responder ofreciendo una lista
de métodos de autenticación al azar, para evitar la divulgación de información
interna del servidor.
4.4.4.
Polı́ticas de Seguridad Locales
Es esencial para la seguridad del servidor mantener una polı́tica de permisos clara y aplicarla adecuadamente. Si bien el cliente debe pedir el servicio
en el momento de autenticación, es posible que este pedido no esté lo suficientemente especificado y que una vez abierta la conexión se solicite acceso
a más servicios o directorios, que pueden no estar autorizados, por lo que la
configuración del servidor debe ser acorde a dichos permisos.
Cada implementación tiene y debe aclarar su polı́tica de seguridad local
y reglas de acceso por omisión.
4.4.5.
Métodos de Autenticación
Existen consideraciones de seguridad correspondientes a cada uno de los
métodos de autenticación, que deberı́an ser tenidos en cuenta para las configuraciones de los servidores en diferentes situaciones.
Autenticación por Clave Pública
Este método asume que el equipo en el que se encuentra el cliente no
fue comprometido. En ese caso, serı́a posible acceder a la clave privada del
usuario y efectuar la autenticación. La clave privada del cliente se puede
encriptar dentro del cliente para mejorar este aspecto de seguridad, pero no
es condición verificable.
Autenticación por Contraseña
Este método de autenticación asume por un lado, que la encriptación
provista por la capa de transporte es confiable, y además que el servidor no
ha sido violentado. En este último caso, el servidor se podrı́a apropiar del par
nombre de usuario/contraseña, comprometiendo aún más la seguridad en el
mismo.
Autenticación Basada en el Origen
La autenticación basada en el origen asume, naturalmente, que el equipo
de origen es confiable. En caso contrario, se obtendrı́a acceso a toda la red
22
sólo permitiendo la entrada a un servidor comprometido.
4.5.
Análisis
El proceso de autenticación de SSH se maneja en forma sencilla y directa, pero manteniendo flexibilidad en la configuración y robustez de los
procedimientos.
Las vulnerabilidades de seguridad que pueden encontrarse a lo largo del
proceso suelen tener que ver con fallas anteriores (establecimiento débil del
enlace de transporte, compromiso de los equipos intervinientes en la conexión,
etc.), pero de cualquier manera deberı́an ser atendidos, y una de las formas
de hacerlo es estableciendo una configuración que requiera más de un método
de autenticación, y que establezca exigencias de ambos lados de la conexión.
Otro de los puntos en los que conviene prestar atención son las configuraciones de codificación y la habilitación de mensajes de depuración u otros
comportamientos que puedan proveer información sobre el servidor en forma
innecesaria.
23
Capı́tulo 5
Protocolo de Conexión
5.1.
Canales
Luego de una autenticación exitosa sobre la capa de transporte SSH , se
abren múltiples canales a través de la multiplexación . Una conexión multiplexada consiste en muchas señales enviadas sobre un medio común, compartido. Con SSH, canales diferentes son enviados sobre una conexión común
segura.
SSH proporciona sesiones de conexión interactivas, ejecución remota de
comandos, redirección de conexiones TCP/IP y redirección de conexiones
X11.
Ambos clientes y servidores pueden crear un canal nuevo. Luego se le asigna un número diferente a cada canal en cada punta de la conexión. Cuando
el cliente intenta abrir un nuevo canal, los clientes envı́an el número del canal
junto con la petición. Esta información es almacenada por el servidor y usada
para dirigir la comunicación a ese canal. Esto es hecho para que diferentes
tipos de sesión no afecten una a la otra y ası́ cuando una sesión termine, su
canal pueda ser cerrado sin interrumpir la conexión SSH primaria.
Los canales también soportan el control de flujo, el cual les permite enviar
y recibir datos ordenadamente. De esta manera, los datos no se envı́an a
través del canal sino hasta que el host haya recibido un mensaje avisando
que el canal está abierto y puede recibirlos.
El cliente y el servidor negocian las caracterı́sticas de cada canal automáticamente, dependiendo del tipo de servicio que el cliente solicita y la forma
en que el usuario está conectado a la red. Esto otorga una gran flexibilidad
en el manejo de diferentes tipos de conexiones remotas sin tener que cambiar
la infraestructura básica del protocolo.
24
5.1.1.
Apertura de un canal
Cuando cualquier parte quiere abrir un nuevo canal, reserva un número
local para el mismo, y envı́a un mensaje al otro extremo, que incluye el
número local, el tipo de canal que quiere abrir y el tamaño inicial de la
ventana. El extremo remoto decide si puede abrir el canal, y responde con un
mensaje de confirmación, que contiene el número que usará él para el canal,
y el tamaño de la ventana, o bien con un mensaje de fallo, que contiene el
motivo del fallo (un código, y un mensaje).
Las implementaciones cliente rechazarán cualquier pedido de sesión de
canal abierto para que sea más difı́cil para un servidor corrupto atacar al
cliente.
Una pseudo-terminal puede ser asignada para una sesión mediante el
envı́o de un mensaje de solicitud de canal especı́fico, indicando en el tipo de
solicitud pty-req y otros parámetros tales como el tamaño, en filas, columnas
y los pixels de cada una.
5.2.
5.2.1.
Servicios
Sesiones Interactivas
Una sesión es una ejecución remota de un programa. El programa puede
ser una consola, una aplicación, un comando del sistema o un subsistema.
Puede tener o no una terminal y puede requerir redirección de tráfico sobre
X11. Además, múltiples sesiones pueden estar activas a la vez.
Para realizar todas estas operaciones, se enviarán diferentes tipos de mensajes para apertura de canales y solicitud de opciones en los mismos.
Solicitud de transmisión X11
SSH permite ejecutar casi cualquier aplicación basada en el protocolo X
(protocolo gráfico de UNIX) remotamente. Mediante un mesaje de solicitud
de canal especı́fico. El tipo de solicitud es X11-req, el formato del mensaje
es:
byte
uint32
string
boolean
boolean
string
SSH_MSG_CHANNEL_REQUEST
canal del destinatario
"X11-req"
si se requiere respuesta
conexión única (single connection)
protocolo de autenticación X11
25
string
uint32
cookie de autenticación X11
número de pantalla X11
Es recomendable que la cookie de autenticación X11 que se envı́a sea
falsa, una cookie aleatoria (random cookie), y que la cookie sea comprobada y
sustituida por la real cuando la solicitud de conexión es recibida. La conexión
de redirección X11 debe dejar de transmitir cuando el canal de sesión se
esté cerrado. Sin embargo, si ya hay abiertas redirecciones X11, éstos no se
cierran automáticamente cuando el canal de sesión está cerrado.
Si el valor binario single connection es TRUE (verdadero), sólo una
única conexión debe ser redirigida. No más conexiones serán redirigidas después de la primera, o después que el canal de la sesión se haya cerrado.
El “protocolo de autenticación X11” es el nombre del método de autenticación X11 utilizado, por ejemplo, MIT-MAGIC-COOKIE-1. El “cookie de
autenticación X11” debe estar codificado en forma hexadecimal.
Los canales X11 se abren con una solicitud de apertura de canal. Los
canales resultantes son independientes de la sesión, y el cierre del canal de la
sesión no cierra la Redirección de canales X11.
Inicio de una Lı́nea de Comandos (shell)
Una vez que la sesión se ha levantado, un programa se inicia en el lado
remoto. El programa puede ser un shell, un programa de aplicación, o un subsistema con un nombre de host independiente. Sólo una de estas solicitudes
puede tener éxito por canal.
Para solicitar el inicio de una lı́nea de comandos, se envı́a un mensaje con
el siguiente formato:
byte
uint32
string
boolean
SSH_MSG_CHANNEL_REQUEST
canal del destinatario
"shell"
si se requiere respuesta
Transferencia de datos de la Sesión
La transferencia de datos para una sesión se realiza utilizando paquetes
SSH MSG CHANNEL DATA y SSH MSG CHANNEL EXTENDED DATA y el mecanismo
de ventana.
Cuando el control de flujo es permitido, a menudo es conveniente hacer
el control de flujo en el cliente a fin de acelerar las respuestas a las peticiones
del usuario. Inicialmente, el servidor es responsable del control de flujo.
26
5.2.2.
Redirección de puertos TCP / IP
Para solicitar redirección de puertos, la parte remota no necesita solicitar
explı́citamente redirección de su propio extremo hacia la otra dirección. Sin
embargo, si desea que las conexiones a un puerto en el otro lado se redirijan
a la parte local, debe solicitarlo expresamente.
byte
string
boolean
string
uint32
SSH_MSG_GLOBAL_REQUEST
"tcpip-forward"
se require respuesta
bind-address (p.e., "0.0.0.0")
bind-port number
El “bind-address” y el “bind port number” especifican la dirección IP
(o nombre de dominio) y el puerto en el que las conexiones redirigidas van
a ser aceptadas. Algunos strings utilizados para “bind-address” tienen una
semántica especial:
"" significa que las conexiones son aceptadas sobre todos los protocolos
soportados por la implementación SSH.
"0.0.0.0" escuchar en todas las direcciones IPv4.
"::" significa escuchar a todas las direcciones IPv6.
"localhost" significa escuchar a todos los protocolos soportados por
la implementación SSH sólo en la dirección de loopback.
"127.0.0.1" y ": 1:" indican la escucha en las interfaces de loopback
para IPv4 e IPv6, respectivamente.
El cliente todavı́a puede filtrar las conexiones basadas en información
mandada en la solicitud de apertura.
Las implementaciones sólo permiten la redirección privilegiada de puertos
si el usuario ha sido autenticado como un usuario privilegiado. Si un cliente pasa 0 como ”bind-port number ”se requiere respuestaçomo TRUE, a
continuación el servidor asigna el próximo número de puerto disponible no
privilegiado y responde indicando el puerto asignado, de lo contrario, no hay
respuesta especı́fica de datos.
Una redirección de puertos puede ser cancelada con el siguiente mensaje, las solicitudes de apertura de canal pueden ser recibidas hasta que una
respuesta a este mensaje sea recibido.
2
27
byte
string
boolean
string
uint32
SSH_MSG_GLOBAL_REQUEST
"cancel-tcpip-forward"
si se requiere respuesta
bind-address(p.e., "127.0.0.1")
bind-port number
Redirección de canales TCP / IP
Cuando una conexión llega a un puerto remoto para el cual la redirección
ha sido solicitada, el canal es abierto para redirigir ese puerto hacia el otro
lado.
Cuando una conexión llega a un puerto local TCP / IP, el siguiente paquete es enviado a la otra parte. Hay que tener en cuenta que estos mensajes
también pueden ser enviados a los puertos para los cuales no ha sido solicitado
explı́citamente redirección. La parte receptora debe decidir si lo permite.
byte
string
uint32
uint32
uint32
string
uint32
string
uint32
SSH_MSG_CHANNEL_OPEN
"direct-tcpip"
canal del remitente
tama~
no inicial de ventana
máximo tama~
no de paquete
host to connect
port to connect
dirección IP originaria
puerto originario
El “host to connect” y el “port to connect” especifican el host TCP / IP
y el puerto donde el receptor debe conectar el canal. El “host to connect”
puede ser un nombre de dominio o una dirección numérica IP. La “dirección
IP originaria” es la dirección numérica IP de la máquina desde donde la
solicitud de conexión es originaria, y el “puerto originario” es el puerto en
el host desde donde se originó la conexión. En la redirección TCP / IP, los
canales son independientes de todas las sesiones, y el cierre del canal de una
sesión no implica en modo alguno que la conexión de redirección sea cerrada.
28
5.3.
5.3.1.
Mensajes
Sumario de Mensajes
Código
SSH MSG GLOBAL REQUEST
No
80
SSH
SSH
SSH
SSH
MSG
MSG
MSG
MSG
REQUEST
REQUEST
CHANNEL
CHANNEL
SUCCESS
FAILURE
OPEN
OPEN CONFIRMATION
81
82
90
91
SSH
SSH
SSH
SSH
MSG
MSG
MSG
MSG
CHANNEL
CHANNEL
CHANNEL
CHANNEL
OPEN FAILURE
WINDOW ADJUST
DATA
EXTENDED DATA
92
93
94
95
SSH
SSH
SSH
SSH
SSH
MSG
MSG
MSG
MSG
MSG
CHANNEL
CHANNEL
CHANNEL
CHANNEL
CHANNEL
EOF
CLOSE
REQUEST
SUCCESS
FAILURE
96
97
98
99
100
5.3.2.
Significado
Solicitud de requerimiento
global
Exito en la solicitud
Falla en la solicitud
Apertura de un canal
Confirmación de apertura del
canal
Falla en la apertura del canal
Ajuste del tamaño de ventana
Transferencia de datos
Transferencia de datos de
error estándar (stderr).
Fin de datos
Cierre del canal
Solicitud de canal especı́fico
Exito de la solicitud de canal
Falla en la solicitud de canal
Detalle del formato de los mensajes
Solicitud de requerimiento global
byte SSH_MSG_GLOBAL_REQUEST
Uint32 canal del destinatario
String tipo de solicitud sòlo en US-ASCII
boolean si se requiere respuesta
.... tipo especifico de dato
Apertura de un canal
byte SSH_MSG_CHANNEL_OPEN
String tipo de canal cadena en US-ASCII
Uint32 canal del remitente
Uint32 tama~
no de la ventana inicial
Uint32 tama~
no máximo de paquete
29
Ajuste del tamaño de ventana
byte SSH_MSG_CHANNEL_WINDOW_ADJUST
Uint32 canal del destinatario
Uint32 bytes a a~
nadir
Transferencia de datos
byte SSH_MSG_CHANNEL_DATA
Uint32 canal del destinatario
String cadena de datos
Transferencia de datos de error estándar (stderr)
byte SSH_MSG_CHANNEL_EXTENDED_DATA
Uint32 canal del destinatario
Uint32 data_type_code
String cadena de datos
Fin del envı́o de datos
byte SSH_MSG_CHANNEL_EOF
Uint32 canal destino
Cierre del canal
byte SSH_MSG_CHANNEL_CLOSE
Uint32 canal destino
Solicitud de canal especı́fico
byte SSH_MSG_CHANNEL_REQUEST
Uint32 canal del destinatario
String tipo de solicitud sòlo en US-ASCII
boolean si se requiere respuesta
.... tipo especifico de dato
5.4.
Consideraciones de Seguridad
Se asume que este protocolo corre por encima de una capa de transporte segura y autenticada. La autenticación del usuario y protección contra
ataques a la red, es provista por protocolos subyacentes.
30
5.5.
Análisis
El protocolo de conexión ofrece una interfaz lo suficientemente sencilla
como para posibilitar una implementación ágil y robusta, y lo suficientemente
flexible como para permitir una funcionalidad amplia y la extensibilidad a
otros protocolos o servicios por encima de los descriptos.
31
Capı́tulo 6
Conclusiones
6.1.
Caracterı́sticas de Uso
El diseño sencillo y modular del protocolo SSH permite la implementación de clientes pequeños y livianos para aplicaciones especı́ficas o para usos
tradicionales como la ejecución remota de comandos, ası́ como su difusión y
utilización en dispositivos móviles, embebidos, y una variedad de diferentes
arquitecturas.
Por otro lado, la flexibilidad de la especificación provee una gran variedad
de servicios y funcionalidades en sı́ mismos, y la posibilidad de montar otros
protocolos adicionales sobre otros servicios.
Pueden mencionarse algunos de los usos más comunes y posibilidades que
provee SSH:
Administración remota y segura de servidores mediante el acceso a
través de la lı́nea de comandos
Utilización de una PC de escritorio en forma remota y acceso a los
datos a través de la redirección del entorno gráfico X11
Transferencia segura de archivos mediante la utilización del subprotocolo SCP
Montaje del sistema de archivos SSHFS, implementado sobre el subprotocolo SFTP
Establecimiento de túneles seguros entre subredes para el flujo de datos
en una red insegura, a través de la redirección de puertos
Redirección de puertos encriptada para evitar bloqueos de puertos o
protocolos
32
6.2.
Caracterı́sticas de Seguridad
Las caracterı́sticas de seguridad del protocolo han sido discutidas extensivamente a lo largo del documento. En términos generales, se puede decir
que es un protocolo seguro y confiable, sin requerir excesiva complejidad ni
capacidad de procesamiento en su implementación.
Las principales vulnerabilidades que se podrı́an explotar y sus posibles
escenarios son:
El ataque Man-in-the-middle (hombre en el medio), que consiste en la
conexión de parte de un agente intermedio con los dos extremos. Este
ataque se puede llevar a cabo si el cliente no conoce de antemano la
clave pública del servidor, en cuyo caso el atacante se hace pasar por
el servidor sin ser detectado.
La posibilidad de que los equipos del servidor o el cliente hayan sido
comprometidos previamente, lo que pone en riesgo la integridad del
otro equipo y la exposición de información sensible (como claves de
acceso o cualquier otra información transmitida).
La posibilidad de una configuración incorrecta del servidor (y ocasionalmente del cliente) que permita un acceso, autenticación o encriptación
lo suficientemente débiles como para que agentes maliciosos puedan
acceder a los datos o usurpar la identidad de otros usuarios.
Existen posibles fallas de implementación del protocolo o de algunos de
sus componentes que también pueden poner en riesgo la seguridad del
sistema (como fue el caso de la falla en el generador de números aleatorios de la biblioteca SSL que afectó todos los aspectos de seguridad
de toda la familia Debian entre septiembre de 2006 y mayo de 2008).
Más allá de estas situaciones especı́ficas y algunas otras más particulares,
el protocolo aporta la seguridad de ser un estándar abierto, lo que permite
que pueda ser estudiado, revisado y verificado por todo aquél que lo desee.
6.3.
Conclusión General
Creemos que se trata de un protocolo extremadamente útil y flexible, que
aunque ya tiene una difusión razonable, puede ser explotado masivamente y
a para una infinidad de aplicaciones con un costo computacional mı́nimo.
Su utilización sistemática por debajo de cualquier aplicación de red permitirı́a la presevación de la privacidad de los usuarios e impedirı́a el robo
33
de información personal en la mayorı́a de aquellas que suelen transmitir los
datos sin encriptación alguna.
34
Capı́tulo 7
Ejemplos
En todos los casos se utilizará para las pruebas el cliente openssh instalado en un sistema Linux.
7.1.
7.1.1.
Sesiones Interactivas
Sesión de Lı́nea de comandos
Se conecta al servidor de SSH logos con el usuario “user” local y usuario
“user2” remoto utilizando el puerto por omisión (22), iniciando una sesión
de lı́nea de comandos:
user@tania:~$ ssh user2@logos
user2@logos’s password:
Linux logos 2.6.24-19-generic #1 SMP Wed Aug 20 22:56:21 UTC 2008 i686
Welcome :-)
Last login: Sun Nov 2 20:37:29 2008 from 10.10.10.10
user2@logos:~$ xeyes
Error: Can’t open display:
Una vez en logos, se intenta iniciar una aplicación gráfica que es rechazada por no haber solicitado redirección de entorno gráfico X11.
7.1.2.
Sesión de redirección de X11
Se conecta al servidor de SSH logos con el usuario “user” local y remoto
(por lo que se puede omitir) utilizando el puerto por omisión (22), iniciando
una sesión de lı́nea de comandos con redirección de entorno gráfico:
35
user@tania:~$ ssh -X logos
user@logos’s password:
Linux logos 2.6.24-19-generic #1 SMP Wed Aug 20 22:56:21 UTC 2008 i686
Welcome :-)
Last login: Sun Nov
user@logos:~$ xeyes
2 20:42:13 2008 from 10.10.10.10
En este caso el programa gráfico invocado xeyes se inicia correctamente.
7.2.
7.2.1.
Redirección de Puertos TCP/IP
Túnel local o saliente
Aquı́ el parámetro -N indica que no se abrirá una sesión de lı́nea de
comandos, y el parámetro -L solicita abrir un túnel local: todo el tráfico
que llegue al puerto 5555 del cliente será redireccionado al puerto 5 del
sistema localhost (resuelto desde el servidor de SSH, por lo que en este
caso localhost refiere al sistema logos).
user@tania:~$ ssh -N -L 5555:localhost:5 logos
user@logos’s password:
user@tania:~$
El túnel quedará abierto hasta que se cierre la conexión.
7.2.2.
Túnel remoto, entrante o inverso
Comando similar al anterior, pero donde el parámetro -R indica que el
túnel es remoto, lo que quiere decir que el tráfico entrante al puerto 5555
del servidor se redirigirá al puerto 5 de localhost (en este caso el cliente, es
decir tania).
user@tania:~$ ssh -N -R 5555:localhost:5 logos
user@logos’s password:
user@tania:~$
Nuevamente, el túnel se mantendrá abierto hasta que se cierre la conexión
SSH.
36
Capı́tulo 8
Referencias
O’REILLY ”SSH: The Secure Shell - The Definitive Guide”
Network Working Group: RFC 4251 - The Secure Shell (SSH) Protocol
Architecture”
Network Working Group: RFC 4253 - The Secure Shell (SSH) Transport Layer Protocol”
Network Working Group: RFC 4252 - The Secure Shell (SSH) Authentication Protocol”
Network Working Group: RFC 4254 - The Secure Shell (SSH) Connection Protocol”
Network Working Group: RFC 4250 - The Secure Shell (SSH) Protocol
Assigned Numbers”
Network Working Group: RFC 4419 - Diffie-Hellman Group Exchange
for the Secure Shell (SSH) Transport Layer Protocol”
37