El protocolo SSH; su funcionamiento en capas.

Considero que lo que me han enviado es suficientemente claro y explicativo, así que cito textualmente de Guillem Cantallops...

El protocolo SSH tiene varias capas. Las más bajas e importantes, que temporalmente se suceden por este orden, son la de transporte y la de autentificación.

• La de transporte proporciona una negociación inicial de algoritmos (todavia sin cifrar) y luego un intercambio de claves que acaba con autentificación por parte del servidor y una conexión criptográficamente segura.
• La de autentificación descansa sobre la capa anterior y usa sus servicios para que el cliente se autentifique; aunque hay varios métodos, incluyendo passwords corrientes tunelizados por la conexión ya cifrada mediante algoritmo simétrico, el que nos interesa es el que usa algoritmos de clave pública/privada. Por supuesto, el cliente (cada usuario) tiene un par de claves para autentificarse ante el servidor, y el servidor (cada máquina) tiene un par de claves para autentificarse ante el cliente.

Vamos con la capa de transporte. El cliente se conecta al servidor.

Tras ponerse de acuerdo sobre las versiones y otros detalles similares, tiene lugar un intercambio de claves tipo Diffie-Hellman. Es largo de explicar, pero matemáticamente eso permite que dos partes deriven un secreto compartido comunicándose a través de un canal inseguro sin que un hipotético pinchazo en la conexión permita averiguar ese secreto. En el proceso se usan las claves públicas/privadas, y existe la posibilidad de que se produzca un ataque de tipo man-in-the-middle.

El secreto compartido que derivan ambas partes, cliente y servidor, es una clave para un algoritmo simétrico (mucho menos costoso que los de asimétricos o de clave pública/privada) que es lo que se usa realmente para cifrar la comunicación en ambos sentidos. En esta etapa además se verifica mediante firmas la identidad del servidor, para asegurar que no lo están suplantando.

Después, sobre ese canal seguro y sabiendo que el servidor es realmente el que debe ser, se autentifica el cliente. Si se usan algoritmos de clave pública/privada, se hace de manera similar pero a la inversa: mediante firmas digitales hechas por el cliente con la clave privada del cliente, y verificadas por el servidor con la clave pública del cliente.

Por esta razón existe el fichero ~/.ssh/known_hosts, en la parte cliente. En un ataque man-in-the-middle se coloca alguien enmedio y suplanta el cliente para el servidor y el servidor para el cliente, de manera que cliente y servidor no están mutuamente autentificados pero toda la comunicación pasa por el man-in-the-middle de forma transparente y sí existe una autentificación extremo a extremo. Para evitar el man-in-the-middle en un sentido, para evitar que alguien suplante al servidor, la primera vez que te conectas a una máquina el ssh te muestra un hash de su clave pública y te pregunta si es la adecuada. Se supone que lo verificas, y si la aceptas se guarda su dirección IP y esa clave pública en tu ~ /.ssh/known_hosts. Cada vez que te conectas en el futuro a esa máquina se verifica que esos datos coincidan, y si cambian te muestra un mensaje bastante aparente para que sospeches que pasa algo malo; por esta razón existe el fichero ~/.ssh/authorized_keys, en la parte del servidor. En él están las claves públicas de los clientes que están autorizados a conectarse a esa cuenta en esa máquina.

Por lo tanto, si lo que quieres es conectarte a un servidor usando tu clave pública lo que tienes que hacer es generar un par de claves si todavia no lo habias hecho, y añadir tu clave pública al ~/.ssh/authorized_keys de tu cuenta del servidor. La primera vez que te conectes te pedirá que verifiques la clave pública del servidor y si la aceptas automáticamente la guardará en el ~/.ssh/known_hosts de tu cuenta del cliente. Ya está, a no ser que cambie alguna de esas dos claves o la IP del servidor no te preguntará nada más y te conectarás sin password. No es necesario hacer los pasos simétricos para que el servidor pueda tomar la iniciativa de conectarse al cliente, y en general es una muy mala idea hacerlo.