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 (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.
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.
Una conexión SSH se establece en varias fases:
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)?
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.
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: