Soy nuevo en el dominio de seguridad y quería entender este error que recibo:
com.jcraft.jsch.JSchException: UnknownHostKey: 127.0.0.1. La huella digital de la clave RSA es a2:39:3f:44:88:e9:1f:d7:d1:71:f4:85:98:fb:90:dc en com.jcraft.jsch.Session.checkHost(Session.java: 797) en com.jcraft.jsch.Session.connect(Session.java:342) en com.jcraft.jsch.Session.connect(Session.java:183) en FileTransfer.main(FileTransfer.java:37) El proceso salió con código de salida 0.
qué se entiende por `unknownHostKey: 127.0.0.1. clave RSA
la huella digital es a2:39:3f:44:88:e9:1f:d7:d1:71:f4:85:98:fb:90:dc`
Necesito configurar un archivo llamado known_hostsarchivo para corregir este error:
Intenté configurarlo así:
127.0.0.1
Pero esto no funciona. ¿Estoy entendiendo mal lo que se entiende por known_hostsarchivo?
Respuesta1
El crédito por esta respuesta es paraGillesdesde elSitio de seguridad de StackExchange, como su/ellacorreoexplicar known_hostsy authorized_keyslos archivos es un buen punto de partida para comprender este componente de SSH/SFTP.
Vea abajo:
El known_hostsarchivo permite al cliente autenticar el servidor para comprobar que no se está conectando a un imitador. El authorized_keysarchivo 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 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 dice 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 en el cliente.
Por cierto, known_hostspuede contener cualquier tipo de clave pública compatible con la implementación SSH, no solo DSA (también RSA y ECDSA).
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 la 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.