18.3. Secuencia de eventos de una conexión SSH
La siguiente serie de eventos lo ayudan a proteger la integridad de la comunicación SSH entre dos host.
Se lleva a cabo un 'handshake' (apretón de manos) encriptado para que el cliente pueda verificar que se está comunicando con el servidor correcto.
La capa de transporte entre el cliente y la máquina remota es encriptada mediante un código simétrico.
El cliente se autentica ante el servidor.
El cliente remoto puede ahora con tranquilidad interactuar con la máquina remota sobre la conexión encriptada.
18.3.1. Capa de transporte
El papel principal de la capa de transporte es facilitar una comunicación segura entre los dos hosts en el momento y después de la autenticación. La capa de transporte lleva esto a cabo 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
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á. OpenSSH evita este problema permitiendo que el cliente acepte la clave de 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 de host del servidor se puede verificar con la versión guardada en el cliente, proporcionando la confianza que el cliente está realmente comunicando con el servidor deseado. Si en el futuro, la clave del host ya no coincide, el usuario eliminará la versión guardada antes de que una conexión ocurra.
 | Atención |
|---|---|
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 de 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 ejecució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.
18.3.2. Autenticación
Cuando la capa de transporte haya construido un túnel seguro para transmitir información entre los dos sistemas, el servidor le dirá al cliente de los diferentes métodos de autenticación soportados, tales como el uso de firmas privadas codificadas con claves o la inserción de una contraseña. El cliente entonces intentará autenticarse ante el servidor mediante el uso de cualquiera de los métodos soportados.
Ya que los servidores y clientes SSH se pueden configurar para que concedan varios tipos de autenticación, lo cual le concede a cada lado la cantidad óptima de control. Luego el servidor podrá decidir qué métodos de encriptación soportará basado en su pauta de seguridad, y el cliente puede elegir el orden en que intentará utilizar los métodos de autenticación entre las opciones a disposición. Gracias a la naturaleza segura de la capa de transporte de SSH, hasta métodos de autenticación que parecen inseguros, como la autenticación basada en el host, son en realidad seguros para usar.
18.3.3. Canales
Luego de una autenticación exitosa sobre la capa de transporte SSH, múltiples canales son abiertos a través de la técnica llamada multiplexar[1]. Cada uno de estos canales manejan la conexión para diferentes sesiones de terminal y para sesiones X11.
Ambos clientes y servidores pueden crear un canal nuevo. Cada canal es luego asignado un número diferente 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 inforamció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 afectarán 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.