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

  




 

 

NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
Linuxtopia - CentOS 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