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 2 o cuatrimestre de 2008

Índice general 1. Introducción 3 1.1. Historia.............................. 3 1.2. Implementaciones......................... 4 1.3. Arquitectura............................ 4 2. Convenciones y Nomenclatura 6 2.1. Tipos de Dato........................... 6 2.2. Números de Mensaje....................... 6 2.3. Nomenclatura de Algoritmos................... 6 3. Protocolo de Transporte 10 3.1. Formato de los Mensajes..................... 11 3.2. Protocolo de los Paquetes Binarios............... 12 3.2.1. Compresión y Encriptación............... 13 3.2.2. Integridad de los Datos.................. 14 3.3. Intercambio de Claves...................... 14 3.3.1. Descripción del Intercambio de Claves......... 15 3.3.2. Resultado del intercambio de claves........... 16 3.3.3. Petición de Servicio.................... 17 3.4. Consideraciones de Seguridad y Análisis............ 17 4. Protocolo de Autenticación 18 4.1. Proceso de Autenticación del Cliente.............. 18 4.2. Formato de los Mensajes..................... 19 4.3. Métodos de Autenticación.................... 20 4.3.1. Autenticación por Clave Pública............. 20 4.3.2. Autenticación por Contraseña.............. 20 4.3.3. Autenticación Basada en el Origen........... 21 4.4. Consideraciones de Seguridad.................. 21 4.4.1. Fallas en la Capa de Transporte............. 21 4.4.2. Mensajes de Depuración................. 21 1

4.4.3. Nombres de Usuario Inexistentes............ 21 4.4.4. Políticas de Seguridad Locales.............. 22 4.4.5. Métodos de Autenticación................ 22 4.5. Análisis.............................. 23 5. Protocolo de Conexión 24 5.1. Canales.............................. 24 5.1.1. Apertura de un canal................... 25 5.2. Servicios.............................. 25 5.2.1. Sesiones Interactivas................... 25 5.2.2. Redirección de puertos TCP / IP............ 27 5.3. Mensajes.............................. 29 5.3.1. Sumario de Mensajes................... 29 5.3.2. Detalle del formato de los mensajes........... 29 5.4. Consideraciones de Seguridad.................. 30 5.5. Análisis.............................. 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 35 7.1. Sesiones Interactivas....................... 35 7.1.1. Sesión de Línea de comandos.............. 35 7.1.2. Sesión de redirección de X11............... 35 7.2. Redirección de Puertos TCP/IP................. 36 7.2.1. Túnel local o saliente................... 36 7.2.2. Túnel remoto, entrante o inverso............ 36 8. Referencias 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 boolean uint32 uint64 Tamaño Comentarios 8 Puede agruparse en arreglos (arrays) de tipo byte[n] 8 Aunque representa un valor binario, se representa con 8 bits. El valor0representafalso y cualquier otro valor representa VERDADERO, aunque sólo los valores 0 y 1 deberían almacenarse. 32 Representa un entero sin signo de 32 bits, almacenado como 4 bytes de significativiad descendiente. 64 Representa un entero sin signo de 64 bits, almacenado como 8 bytes de significativiad descendiente. string variable 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. mpint variable 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. name-list variable 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 de Transporte 1 a 19 Mensajes genéricos de la capa de transporte 20 a 29 Negociación de algoritmos 30 a 49 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 Prioridad Descripción Algoritmos de Encriptación 3des-cbc Obligatorio 3DES de tres claves con CBC blowfish-cbc Optativo Blowfish con CBC twofish256-cbc Optativo Twofish de 256 bits con CBC twofish-cbc Optativo Twofish de 256 bits con CBC (nombre mantenido por razones históricas) twofish192-cbc Optativo Twofish de 192 bits con CBC twofish128-cbc Optativo Twofish de 128 bits con CBC aes256-cbc Optativo AES de 256 bits con CBC aes192-cbc Optativo AES de 192 bits con CBC aes128-cbc Recomendado AES de 128 bits con CBC serpent256-cbc Optativo Serpent de 256 bits con CBC serpent192-cbc Optativo Serpent de 192 bits con CBC serpent128-cbc Optativo Serpent de 128 bits con CBC arcfour Optativo Cifrado de flujos ARCFOUR de 128 bits idea-cbc Optativo IDEA con CBC cast128-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 HMAC- SHA1 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 HMAC- MD5 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 diffie-hellman-group14-sha1 Obligatorio en Internet (IKE) 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 Descripción SSH MSG DISCONNECT 1 Desconexión SSH MSG IGNORE 2 Ignorar el mensaje de datos SSH MSG UNIMPLEMENTED 3 No implementados SSH MSG DEBUG 4 Depuración SSH MSG SERVICE REQUEST 5 Solicitud de servicio SSH MSG SERVICE ACCEPT 6 Aceptación del servicio SSH MSG KEXINIT 20 Negociación de algoritmos SSH MSG NEWKEYS 21 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 REQUEST SSH MSG USERAUTH FAILURE SSH MSG USERAUTH SUCCESS SSH MSG USERAUTH BANNER Estos mensajes tienen el siguiente formato: Número Descripción 50 Pedido de autenticación 51 Falla en la autenticación 52 Éxito en la autenticación 53 Aviso de autenticación 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 autenticación Tipo Información byte Número de mensaje (53) string Mensaje en codificación UTF-8 string Identificador de idioma 4.3. 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 Prioridad Descripción publickey Obligatorio Clave pública password Optativo Contraseña hostbased Optativo Basado en el Origen none No recomendado Sin autenticación 4.3.1. 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. Servicios 5.2.1. 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 SSH_MSG_CHANNEL_REQUEST uint32 canal del destinatario string "X11-req" boolean si se requiere respuesta boolean conexión única (single connection) string 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 SSH_MSG_CHANNEL_REQUEST uint32 canal del destinatario string "shell" boolean 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 SSH_MSG_GLOBAL_REQUEST string "tcpip-forward" boolean se require respuesta string bind-address (p.e., "0.0.0.0") uint32 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 SSH_MSG_GLOBAL_REQUEST string "cancel-tcpip-forward" boolean si se requiere respuesta string bind-address(p.e., "127.0.0.1") uint32 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. Mensajes 5.3.1. Sumario de Mensajes Código N o Significado SSH MSG GLOBAL REQUEST 80 Solicitud de requerimiento global SSH MSG REQUEST SUCCESS 81 Exito en la solicitud SSH MSG REQUEST FAILURE 82 Falla en la solicitud SSH MSG CHANNEL OPEN 90 Apertura de un canal SSH MSG CHANNEL OPEN CONFIRMATION 91 Confirmación de apertura del canal SSH MSG CHANNEL OPEN FAILURE 92 Falla en la apertura del canal SSH MSG CHANNEL WINDOW ADJUST 93 Ajuste del tamaño de ventana SSH MSG CHANNEL DATA 94 Transferencia de datos SSH MSG CHANNEL EXTENDED DATA 95 Transferencia de datos de error estándar (stderr). SSH MSG CHANNEL EOF 96 Fin de datos SSH MSG CHANNEL CLOSE 97 Cierre del canal SSH MSG CHANNEL REQUEST 98 Solicitud de canal específico SSH MSG CHANNEL SUCCESS 99 Exito de la solicitud de canal SSH MSG CHANNEL FAILURE 100 Falla en la solicitud de canal 5.3.2. 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