En los primeros mensajes entre el cliente y el servidor, ambos envían su lista de algoritmos compatibles, en orden de preferencia. Luego, el algoritmo que se utilizará es el primero en la lista de clientes que también aparece en algún lugar de la lista de servidores. Esto se especifica en RFC 4253, sección 7.1 :
encryption_algorithms
A name-list of acceptable symmetric encryption algorithms (also
known as ciphers) in order of preference. The chosen
encryption algorithm to each direction MUST be the first
algorithm on the client's name-list that is also on the
server's name-list. If there is no such algorithm, both sides
MUST disconnect.
(...)
mac_algorithms
A name-list of acceptable MAC algorithms in order of
preference. The chosen MAC algorithm MUST be the first
algorithm on the client's name-list that is also on the
server's name-list. If there is no such algorithm, both sides
MUST disconnect.
En otras palabras, el protocolo es tal que las preferencias del cliente tienen prioridad sobre las preferencias del servidor.
El modelo normal de SSH (para SSH v1 y v2) es que el cliente recuerda la clave pública del servidor. Cuando el cliente se conecta por primera vez a un servidor dado, el cliente muestra el hash de la clave pública del servidor aparente al usuario; se supone que el usuario debe verificar ese hash con respecto a algún valor de referencia proporcionado por un administrador de sistemas confiable (por ejemplo, el usuario puede llamar al administrador del sistema del servidor para obtener el valor de hash esperado, y comparar). El software del cliente recordará esa clave pública (por ejemplo, en el archivo .ssh/known_hosts
), y las conexiones adicionales verificarán la clave del servidor simplemente comparándola con el valor recordado.
Este modelo es vulnerable a MitM solo si el atacante actúa durante la primera conexión, y si el usuario humano es perezoso y no verifica el valor hash como debería (en la práctica, el 99% de los usuarios humanos son perezosos).
Este modelo no ha cambiado entre SSH v1 y v2. Sin embargo, las implementaciones modernas de SSH v2 también opcionalmente (pero no comúnmente) incursionan en certificados , permitiendo el uso de un modelo basado en CA en lugar del modelo tradicional explicado anteriormente. Sin embargo, todavía tengo que ver que los certificados para SSH realmente se usan en la práctica.