¿Cuál es la diferencia entre authorized_keys y known_hosts file para SSH?

El archivo known_hosts le permite al cliente autenticar el servidor para verificar que no se está conectando a un imitador. El archivo authorized_keys le permite al servidor autenticar al usuario.

Autenticación del servidor

Una de las primeras cosas que sucede cuando se establece la conexión SSH es que el servidor envía su clave pública al cliente y prueba (gracias a criptografía de clave pública ) al cliente que conoce la clave privada asociada. Esto autentica el servidor: si esta parte del protocolo tiene éxito, el cliente sabe que el servidor es quien dice ser.

El cliente puede verificar que el servidor sea conocido y no un servidor falso que intente pasar por el correcto. SSH proporciona solo un mecanismo simple para verificar la legitimidad del servidor: recuerda los servidores a los que ya se conectó, en el archivo ~/.ssh/known_hosts en la máquina cliente (también hay un archivo de todo el sistema /etc/ssh/known_hosts ). La primera vez que se conecta a un servidor, debe verificar por algún otro medio que la clave pública presentada por el servidor es realmente la clave pública del servidor al que desea conectarse. Si tiene la clave pública del servidor al que está a punto de conectarse, puede agregarla a ~/.ssh/known_hosts en el cliente manualmente.

Por cierto, known_hosts puede contener cualquier tipo de clave pública compatible con la implementación de SSH, no solo DSA (también RSA y ECDSA).

La autenticación del servidor se debe realizar antes de enviarle cualquier información confidencial. En particular, si la autenticación del usuario implica una contraseña, la contraseña no debe enviarse a un servidor no autenticado.

Autenticación de usuario

El servidor solo permite que un usuario remoto inicie sesión si ese usuario puede probar que tiene derecho a acceder a esa cuenta. Dependiendo de la configuración del servidor y la elección del usuario, el usuario puede presentar una de varias formas de credenciales (la lista a continuación no es exhaustiva).

• El usuario puede presentar la contraseña de la cuenta en la que está intentando iniciar sesión; el servidor luego verifica que la contraseña sea correcta.
• El usuario puede presentar una clave pública y probar que posee la clave privada asociada con esa clave pública. Este es exactamente el mismo método que se usa para autenticar el servidor, pero ahora el usuario está tratando de probar su identidad y el servidor lo está verificando. Se acepta el intento de inicio de sesión si el usuario prueba que conoce la clave privada y que la clave pública está en la lista de autorizaciones de la cuenta ( ~/.ssh/authorized_keys en el servidor).
• Otro tipo de método implica delegar parte del trabajo de autenticación del usuario a la máquina cliente. Esto sucede en entornos controlados como las empresas, cuando muchas máquinas comparten las mismas cuentas. El servidor autentica la máquina cliente mediante el mismo mecanismo que se usa al revés, luego confía en el cliente para autenticar al usuario.

Estos dos archivos son utilizados por SSH pero para propósitos completamente diferentes, lo que podría explicar fácilmente su confusión.

Claves autorizadas

De forma predeterminada, SSH usa cuentas de usuario y contraseñas que son administradas por el sistema operativo host. (Bueno, en realidad administrado por PAM pero esa distinción probablemente no sea muy útil aquí). Lo que esto significa es que cuando intente conectarse a SSH con el nombre de usuario 'bob' y alguna contraseña que el programa del servidor SSH le preguntará al sistema operativo "Tengo un tipo llamado 'bob' que me dice que su contraseña es 'wonka'. ¿Puedo dejarlo entrar?" Si la respuesta es sí, entonces SSH te permite autenticarte y seguir tu camino alegre.

Además de las contraseñas, SSH también le permitirá usar lo que se llama criptografía de clave pública para identificarlo. El algoritmo de cifrado específico puede variar, pero generalmente es RSA o DSA , o más recientemente ECDSA . En cualquier caso, cuando configura sus claves, utilizando el programa ssh-keygen , crea dos archivos. Una que es su clave privada y otra que es su clave pública. Los nombres son bastante autoexplicativos. Por diseño, la clave pública puede ser esparcida como semillas de diente de león en el viento sin comprometerte. La clave privada siempre debe mantenerse en la más estricta confidencialidad.

Entonces, lo que haces es colocar tu clave pública en el archivo authorized_keys . Luego, cuando intentes conectarte a SSH con el nombre de usuario 'bob' y tu clave privada, se le preguntará al sistema operativo "Tengo este nombre de chico 'bob', ¿puedes estar aquí?" Si la respuesta es sí, SSH inspeccionará su clave privada y verificará si la clave pública en el archivo authorized_keys es su par. Si ambas respuestas son afirmativas, se te permite ingresar.

Hosts conocidos

Al igual que la forma en que se usa el archivo authorized_keys para autenticar a los usuarios, el archivo known_hosts se usa para autenticar los servidores. Cada vez que se configura SSH en un servidor nuevo, siempre genera una clave pública y privada para el servidor, tal como lo hizo para su usuario. Cada vez que se conecta a un servidor SSH, le muestra su clave pública, junto con una prueba de que posee la clave privada correspondiente. Si no tiene su clave pública, su computadora la solicitará y la agregará al archivo known_hosts . Si tiene la clave y coincide, entonces se conecta de inmediato. Si las teclas no coinciden, obtienes una gran advertencia desagradable. Aquí es donde las cosas se ponen interesantes. Las 3 situaciones en las que suele suceder una falta de coincidencia de claves son:

1. La clave cambió en el servidor. Esto podría deberse a la reinstalación del OS o en algunos sistemas operativos la clave se vuelve a crear al actualizar SSH.
2. El nombre de host o la dirección IP a la que se está conectando se utiliza para pertenecer a un servidor diferente. Esto podría ser la reasignación de direcciones, DHCP , o algo similar.
3. Malicioso ataque del hombre en el medio está ocurriendo. Esto es lo más importante de lo que intenta protegerte la clave.

En ambos casos, known_hosts y authorized_keys , el programa SSH usa criptografía de clave pública para identificar al cliente o al servidor.

No es cierto en absoluto.

El archivo known_hosts contiene la huella digital del host. No es la clave pública o privada del host remoto.

Se genera a partir de su clave, pero enfáticamente NO es la clave en sí misma.

Si transfiere SFTP a una dirección que podría resolverse en varios hosts (diferentes) (carga equilibrada, etc.) debe agregar las huellas dactilares de todos los puntos finales posibles, o funcionará inicialmente y luego fallará cuando se dirija al segundo (o posterior) host.