Autenticación basada en claves SSH: conocido_hosts vs autorizado_keys

Leí sobre la configuración de claves ssh en Linux y tengo algunas preguntas. Corrígeme si me equivoco…

Digamos que el host tr-lgto quiere conectarse al host tr-mdm usando ssh. Si queremos estar seguros de que es el verdadero tr-mdm, generamos un par de claves en tr-mdm y agregamos la clave pública known_hostsen tr-lgto. Si tr-mdm quiere verificar que es el verdadero tr-lgto, entonces tr-lgto tiene que generar un par de claves y agregar la clave pública a authorized_keystr-mdm.

Pregunta 1 : No hay un campo de usuario en el archivo conocido_hosts, solo direcciones IP y nombres de host. tr-mdm podría tener muchos usuarios, cada uno con su propia .sshcarpeta. ¿Deberíamos agregar la clave pública a cada uno de los known_hostsarchivos?

Pregunta 2 : descubrí que ssh-keyscan -t rsa tr-mdmdevolverá la clave pública de tr-mdm. ¿Cómo sé a qué usuario pertenece esta clave? Además, la clave pública en /root/.ssh/es diferente de lo que devuelve ese comando. ¿Cómo puede ser esto?

Está mezclando la autenticación de la máquina del servidor con la máquina del cliente, y la autenticación del usuario con la máquina del servidor.

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 demuestra (gracias a la 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 pretende ser.

El cliente puede verificar que el servidor es conocido y no un servidor no autorizado que intenta hacerse pasar por el correcto. SSH proporciona solo un mecanismo simple para verificar la legitimidad del servidor: recuerda los servidores a los que ya se ha conectado, en el ~/.ssh/known_hostsarchivo de 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 otros medios 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 se va a conectar, puede agregarla ~/.ssh/known_hostsen el cliente manualmente.

La autenticación del servidor debe realizarse antes de enviarle datos confidenciales. En particular, si la autenticación del usuario implica una contraseña, la contraseña no debe enviarse a un servidor no autenticado.

Autenticacion 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 demostrar que posee la clave privada asociada con esa clave pública. Este es exactamente el mismo método que se utiliza para autenticar el servidor, pero ahora el usuario está tratando de probar su identidad y el servidor los está verificando. El intento de inicio de sesión se acepta si el usuario demuestra que conoce la clave privada y la clave pública está en la lista de autorizaciones de la cuenta ( ~/.ssh/authorized_keysen el servidor).
• Otro tipo de método implica delegar parte del trabajo de autenticación del usuario en 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 por el mismo mecanismo que se usa al revés, luego confía en el cliente para autenticar al usuario.

Mis amigos me dieron la respuesta. Por defecto, la clave identifica una máquina y no un usuario. Entonces las claves se almacenan en / etc / ssh /. Es por eso que obtuve una clave diferente de la almacenada en /root/.ssh