Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Linuxtopia - Red Hat Enterprise Linux 4: Manual de referencia - Secuencia de eventos de una conexi�n SSH

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�nAtenci�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.

Notas

[1]

Una conexi�n multiplexada consiste de muchas se�ales siendo enviadas sobre un medio com�n, compartido. Con SSH, canales diferentes son enviados sobre una conexi�n com�n segura.

 
 
  Published under the terms of the GNU General Public License Design by Interspire