20.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 de la conexi�n 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 interactua con la m�quina remota sobre la conexi�n encriptada.
20.3.1. Capa de transporte
El papel principal de la capa de transporte es facilitar una comunicaci�n segura entre los dos hosts durante la autenticaci�n yla subsecuente comunicaci�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 llave de host �nica durante el intercambio de llaves. Obviamente si este cliente nunca se hab�a comunicado antes con este determinado servidor, la llave del servidor le resultar� desconocida al cliente y no lo conectar�. OpenSSH evita este problema permitiendo que el cliente acepte la llave del host del servidor despu�s que el usuario es notificado y verifica la aceptaci�n de la nueva llave del host. Para las conexiones posteriores, la llave 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 servidor deseado. Si en el futuro, la llave del host ya no coincide, el usuario debe eliminar la versi�n guardada antes de que una conexi�n pueda ocurrir.
 | 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 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.
20.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.
Los servidores y clientes SSH se pueden configurar para que permitan 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 contrase�as, son en realidad seguros para usar.
20.3.3. Canales
Luego de una autenticaci�n exitosa sobre la capa de transporte SSH, se abrenm�ltiples canales 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 de reenvio 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.
