Leí sobre la configuración de claves ssh en Linux y tengo algunas preguntas. Corrígeme si estoy equivocado…
Digamos que el host tr-lgto quiere conectarse al host tr-mdm usando ssh. Si queremos estar seguros de que es el tr-mdm real, generamos un par de claves en tr-mdm y agregamos la clave pública known_hostsen tr-lgto. Si tr-mdm quiere comprobar que es el tr-lgto real, entonces tr-lgto tiene que generar un par de claves y agregar la clave pública a authorized_keystr-mdm.
Pregunta 1: No hayusuariocampo en el archivoknown_hosts, solo direcciones IP y nombres de host. tr-mdm puede 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 /root/.ssh/es diferente de lo que devuelve ese comando. ¿Cómo puede ser esto?
Respuesta1
Estás mezclando la autenticación de la máquina servidor en la máquina cliente y la autenticación del usuario en la máquina 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 prueba (gracias acriptografí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 comprobar que el servidor es conocido y no un servidor fraudulento que intenta hacerse pasar por el correcto. SSH proporciona sólo 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 para 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 sea 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 ~/.ssh/known_hostsmanualmente al cliente.
Es necesario autenticar el servidor 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 demostrar 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 siguiente no es exhaustiva).
- El usuario podrá presentar la contraseña de la cuenta a la que intenta iniciar sesión; Luego, el servidor verifica que la contraseña sea correcta.
- El usuario podrá presentar una clave pública y demostrar que posee la clave privada asociada a esa clave pública. Este es exactamente el mismo método que se utiliza para autenticar el servidor, pero ahora el usuario intenta demostrar su identidad y el servidor lo verifica. El intento de inicio de sesión se acepta si el usuario demuestra que conoce la clave privada y que la clave pública está en la lista de autorización 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 mediante el mismo mecanismo que se utiliza al revés y luego confía en el cliente para autenticar al usuario.
Respuesta2
Mis amigos me dieron la respuesta. De forma predeterminada, 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 a la almacenada en /root/.ssh