¿El mensaje "no se puede establecer la autenticidad del host" en SSH refleja un riesgo de seguridad?

Cada vez que me conecto a un nuevo servidor SSH desde mi computadora recibo este mensaje:

The authenticity of host '[censored]:censored ([0.0.0.0]:censored)' can't be established.
RSA key fingerprint is SHA256:censored.
Are you sure you want to continue connecting (yes/no)?

¿Por qué SSH me pregunta eso?

¿Tengo algún riesgo de conectarme a un servidor SSH aleatorio?

¿O es solo para asegurarse de que el servidor al que se está conectando no ha sido pirateado?

ssh internet-security

— Charles Duffy
fuente

¿Estás utilizando una contraseña o una clave para iniciar sesión?

— kasperd

Hay varias formas mejores de distribuir claves de host que la confianza en el primer uso; Este es un flujo de trabajo relativamente inseguro. Las claves de host se pueden distribuir a través de LDAP; a través de entradas de DNS firmadas; se puede firmar con las autoridades de certificación SSH; Es decir, lo que está viendo aquí indica que su sitio está configurado "de manera perezosa" (¡lo cual es casi todo!), lo que es menos seguro que ir más lejos para hacer las cosas bien.

— Charles Duffy

Respuestas:

Te pregunta porque nunca antes estaba conectado a este host.

Si se encuentra en un entorno seguro, conocerá la huella digital del host remoto y la comparará en la primera conexión; si la huella digital coincide con lo que sabe que debería ser, entonces genial. Si se encuentra en un entorno menos seguro, puede aceptarlo en la primera conexión.

Una vez que haya dicho " Sí, confío en esa clave de host, y quiero que se asocie con ese nombre de host / IP ", el cliente SSH lo recordará por usted ... Si por alguna razón (reinstalar / nuevas claves de host / nuevo máquina / hombre en el medio) la clave no coincide en una conexión posterior, verá una advertencia como la siguiente:

$ ssh baloo
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:Su0uy/4BcRcpmyLfxO9ndlcda52F8uct6yWNp7Sa92M.
Please contact your system administrator.
Add correct host key in /home/attie/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/attie/.ssh/known_hosts:65
  remove with:
  ssh-keygen -f "/home/attie/.ssh/known_hosts" -R baloo
ECDSA host key for baloo has changed and you have requested strict checking.
Host key verification failed.

En esta situación, si sabe que el host remoto ha cambiado, entonces puede continuar ... posiblemente verificando que la huella digital sea correcta.

Si no está seguro o sabe que el host remoto no debería haber cambiado, le dará una pista sobre un posible ataque.

— Attie
fuente

Este es el principio TOFU: Confianza en el primer uso

— Patrick Mevzek

De acuerdo, TOFU no es una gran idea, especialmente si necesita estar seguro ... Su opinión y enfoque dependerán (deberían) de su modelo de hilo.

— Attie

Sin embargo, para la efectividad de esto, ver cs.auckland.ac.nz/~pgut001/pubs/defending.pdf , páginas 45-48.

— Joker_vD

Diapositivas interesantes, gracias por compartir @Joker_vD

— Attie

@PatrickMevzek El problema es que todo nuestro modelo de "confianza" informática se basa fundamentalmente en la granularidad de un valor booleano, mientras que en el mundo real un modelo práctico de confianza (como lo que usamos intuitivamente en las relaciones interhumanas) es más como un probabilidad condicional: dado un reclamo de una entidad, tenemos cierto grado de confianza de que la entidad lo seguirá y limitamos nuestra exposición al riesgo en proporción a eso.

— mtraceur

Cuando recibe este mensaje, SSH simplemente dice: "Nunca antes había visto esta computadora, así que no puedo estar seguro de quién dice que es. ¿Confía en ella?" En ese momento, puede decir que confía en él y en el futuro su computadora recordará y no volverá a preguntarle.

Idealmente para confiar en él, debe comparar manualmente la clave provista con la clave en el servidor (ya que confiaría en una clave GPG al verificar que la persona a quien cree que pertenece realmente puede generar la clave pública). Aunque en realidad la gente no se molesta con esto (al menos desde mi conocimiento).

El beneficio real proviene de cada vez que se conecta al servidor. Si SSH se queja de que el servidor en el que ya confió no es el mismo servidor, existe la posibilidad de que sea víctima de un ataque MiTM.

Sobre todo si está en una red donde está seguro de que no está ocurriendo un ataque de Man in The Middle y esta es la primera vez que se conecta a la computadora, entonces debe estar seguro de aceptar la clave. (aunque si está trabajando en alguna misión gubernamental de alto secreto, entonces quizás le pida al administrador del sistema que verifique la huella digital antes de conectarse)

— KNejad
fuente