Última actualización: lunes 17 octubre 2016 à 16:22 por Carlos Villagómez.
Internet hace posible realizar una gran variedad de operaciones remotas, en especial, administrar un servidor y transferir archivos. El protocolo Telnet y los comandos BSD R (rhs, rlogin y rexec) que permiten que los usuarios realicen estas tareas, tienen la gran desventaja de transmitir el intercambio de información en texto plano en la red, en particular, el nombre de acceso y la contraseña para acceder a equipos remotos. Tal es así que un hacker que se encuentre ubicado en una red entre el usuario y un equipo remoto puede controlar el tráfico, es decir, utilizar una herramienta llamada rastreador que puede capturar paquetes que circulan en la red y obtener el nombre de acceso y la contraseña para acceder al equipo remoto.
Si la información intercambiada no tiene un alto nivel de seguridad, el hacker puede obtener incluso acceso a una cuenta en el equipo remoto y aumentar sus privilegios en este equipo para obtener acceso como administrador.
Ya que es imposible controlar todas las infraestructuras físicas ubicadas entre el usuario y el equipo remoto (al ser Internet una red abierta por definición), la única solución es confiar en la seguridad a un nivel lógico (al nivel de los datos).
El protocolo SSH (Secure Shell) es la respuesta a este problema ya que posibilita a sus usuarios (o servicios TCP/IP) acceder a un equipo a través de una comunicación cifrada (llamada túnel).
El protocolo SSH
El protocolo SSH (Secure Shell) se desarrolló en 1995 por el finlandés Tatu Ylönen.
Este hace posible que un cliente (un usuario o un equipo) inicie una sesión interactiva en una máquina remota (servidor) para enviar comandos o ficheros a través de un canal seguro.
Los datos que circulan entre el cliente y el servidor están cifrados y esto garantiza su confidencialidad (nadie más que el servidor y el cliente pueden leer la información que se envía a través de la red). Como resultado, no es posible controlar la red con un rastreador.
El cliente y el servidor se autentifican uno a otro para asegurarse que las dos máquinas que se comunican son, de hecho, aquellas que las partes creen que son. El hacker ya no puede adoptar la identidad del cliente o de su servidor (falsificación).
El objetivo de la versión 1 del protocolo (SSH1), propuesta en 1995, ofrecía una alternativa a las sesiones interactivas (shells) tales como Telnet, rsh, rlogin y rexec. Sin embargo, este protocolo tenía un punto débil que permitía a los hackers introducir datos en los flujos cifrados. Por este motivo, en 1997 se propuso la versión 2 del protocolo (SSH2) como un anteproyecto del IETF. Se puede acceder a los documentos que definen este protocolo en http://www.ietf.org/html.charters/secsh-charter.html.
Secure Shell Versión 2 también incluye un protocolo SFTP (Secure File Transfer Protocol; en castellano, Protocolo Seguro de Transferencia de Archivos).
SSH es un protocolo, es decir, un método estándar que permite a los equipos establecer una conexión segura. Como tal, existe una variedad de implementaciones de clientes y servidores SSH. Algunas requieren el pago de una cuota, en tanto que otras son gratuitas o de código abierto: puede encontrar algunos clientes SSH en la sección de descargas de commentcamarche.
Cómo funciona SSH
Una conexión SSH se establece en varias fases:
En primera instancia, se determina la identidad entre el servidor y el cliente para establecer un canal seguro (capa segura de transporte).
En segunda instancia, el cliente inicia sesión en el servidor.
Establecer un canal seguro
El establecimiento de una capa segura de transporte comienza con la fase de negociación entre el cliente y el servidor para ponerse de acuerdo en los métodos de cifrado que quieren utilizar. El protocolo SSH está diseñado para trabajar con un gran número de algoritmos de cifrado, por esto, tanto el cliente como el servidor deben intercambiar primero los algoritmos que admiten.
Después, para establecer una conexión segura, el servidor envía al cliente su clave de host. El cliente genera una clave de sesión de 256 bits que cifra con la clave pública del servidor y luego la envía al servidor junto con el algoritmo utilizado. El servidor descifra la clave de sesión con su clave privada y envía al cliente un mensaje de confirmación cifrado con la clave se sesión. Después de esto, las comunicaciones restantes se cifran gracias a un algoritmo de cifrado simétrico, mediante la clave de sesión compartida entre el cliente y el servidor.
La seguridad de la transacción se basa en la confianza del cliente y el servidor en que las claves host de cada una de las partes son válidas. Así, cuando se conecta por primera vez con el servidor, el cliente muestra generalmente un mensaje en el que le pide que acepte la comunicación (y posiblemente le presenta un hash de la clave host del servidor):
Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)?
Para obtener una sesión segura propiamente dicha, es mejor pedirle directamente al administrador del servidor que valide la clave pública presentada. Si el usuario valida la conexión, el cliente guarda la clave host del servidor para evitar tener que repetir esta fase.
Por el contrario, dependiendo de su configuración, el servidor puede, a veces, verificar que el cliente es quien dice ser. Si el servidor tiene un lista de hosts autorizados para la conexión, cifrará el mensaje utilizando la clave pública del cliente (que se encuentra en la base de datos de claves del host) para verificar si el cliente es capaz de descifrarla con su clave privada (esto se llama challenge.
Autentificación
Una vez que se ha establecido la conexión segura entre el cliente y le servidor, el cliente debe conectarse al servidor para obtener un derecho de acceso. Existen diversos métodos:
el método más conocido es la contraseña tradicional. El cliente envía un nombre de acceso y una contraseña al servidor a través de la conexión segura y el servidor verifica que el usuario en cuestión tiene acceso al equipo y que la contraseña suministrada es válida.
un método menos conocido, pero más flexible, es el uso de claves públicas. Si el cliente elige la clave de autentificación, el servidor creará un challenge y le dará acceso al cliente si éste es capaz de descifrar el challenge con su clave privada.
