Cuando me conecto por primera vez a través de SSH a mi servidor, la huella digital reportada no coincide con la que recibí cuando generé la clave SSH

Question

Cuando me conecto por primera vez a través de SSH a mi servidor, la huella digital reportada no coincide con la que recibí cuando generé la clave SSH

#1 de Mike Ounsworth (2 votos)

1

Cuando usé ssh-genkey en macOS para generar el par de archivos clave (uno llamado con .pub ), esa herramienta reportó un SHA256 hash como huella digital de clave pública .

La primera vez que me conecto a mi servidor, una Digital Ocean droplet se ejecuta la instancia del servidor virtual < a href="https://en.wikipedia.org/wiki/FreeBSD"> FreeBSD inicializado con el contenido de mi archivo de clave pública .pub , en el primer intento de conexión con ssh 1.2.3.4 recibo el mensaje :

No se puede establecer la autenticidad del host '1.2.3.4 (1.2.3.4)'.

La huella digital de la clave ECDSA es SHA256: tjdoQBGbHexAm + uwZ5rZwxyJH0nxjMC08QtO47QGQjE.

Esto no parece coincidir con el SHA256 devuelto por ssh-keygen cuando creé los archivos clave.

Algunos sitios parecen decir que debería ignorar este problema. Reclaman que la huella digital clave que aparece cuando me conecto a mi servidor a través de ssh no está relacionada con la huella digital del contenido del archivo de clave pública ssh que cargué en Digital Ocean para usar al crear esa instancia de servidor. Encuentro esto difícil de entender.

¿Qué punto hay en Digital Ocean que insista en que proporcione una clave pública SSH para usar en la configuración de mi nuevo servidor si se ignora o es irrelevante?
¿Qué detiene un ataque Man-In-The-Middle si tengo que ignorar la huella digital reportada durante el primer intento de establecer una conexión / sesión ssh?
¿Por qué ssh incluso informa una huella dactilar clave si queremos ignorarla?

ssh fingerprint

pregunta Basil Bourque 21.11.2018 - 01:56

fuente

1 respuesta

Lea otras preguntas en las etiquetas ssh fingerprint

Replicando acciones javascript de diferentes sitios web (¿XSS?) Codificación binaria a ASCII para hacer que los archivos no sean ejecutables

score 2 · Answer 1

Hay dos teclas separadas en juego aquí:

Su personal la clave ssh del cliente que generó en su computadora portátil, la clave privada está en su computadora portátil y, por lo tanto, esta clave identifica que una conexión se origina desde su computadora portátil.
La clave ssh del servidor que se generó en el servidor durante el primer arranque (al menos supongo que ya que usted dice que solo cargó una clave pública), la clave privada está en el servidor, y, por lo tanto, esta clave identifica que la conexión está terminando en su servidor.

Su pregunta principal parece ser: ¿Qué hace Digital Ocean con la clave pública que cargué durante la creación de la máquina virtual?

Para obtener una respuesta autorizada, tendría que leer la documentación de Digital Ocean, pero supongo que la pegan en /home/user/.ssh/authorized_keys para que su clave pública (también conocida como su computadora portátil) sea la única que pueda conectarse a esa máquina. Consulte esta guía para obtener más información.

Para responder a su segunda y tercera pregunta: los clientes ssh siguen el paradigma Confiar en el primer uso (TOFU) y heredar Todas las fortalezas y debilidades de la misma. No es lo ideal, pero probablemente sea tan bueno como lo que sucedería si tratara de cambiar ssh a certificados: la mitad de los servidores ssh del mundo usarían el certificado predeterminado que se incluye con openssh.