SSH: no se puede establecer la autenticidad del host <host>


81

¿Qué significa este mensaje? ¿Es este un problema potencial? ¿El canal no es seguro?

¿O es simplemente un mensaje predeterminado que siempre se muestra cuando se conecta a un nuevo servidor?

Estoy acostumbrado a ver este mensaje cuando utilizo SSH en el pasado: siempre ingresaba mi nombre de usuario con una contraseña de la manera normal, y me sentía bien porque no estaba usando claves privadas / públicas (lo cual es mucho más seguro que una contraseña corta). Pero esta vez configuré una clave pública con ssh para mi conexión a bitbucket, pero aún recibí el mensaje. Soy consciente de que la solicitud de frase de contraseña al final es una medida de seguridad complementaria diferente para el descifrado de la clave privada.

Espero que alguien pueda dar una buena explicación de lo que significa este mensaje de "no se puede establecer la autenticidad".

The authenticity of host 'bitbucket.org (207.223.240.181)' can't be established.

RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'bitbucket.org,207.223.240.181' (RSA) to the list of
known hosts.
Enter passphrase for key '/c/Users/Steven/.ssh/id_rsa':

2
Este realmente es uno de esos mensajes "significa precisamente lo que dice". Significa que sshno tiene forma de decir que realmente estás hablando bitbucket.org. Si configuró de alguna manera para que lo sepa, entonces no está funcionando. Si no lo hiciste, entonces te está diciendo que no lo hiciste.
David Schwartz

Respuestas:


69

Te dice que nunca antes te has conectado a este servidor. Si esperabas eso, es perfectamente normal. Si eres paranoico, verifica la suma de comprobación / huella digital de la clave usando un canal alternativo. (Pero tenga en cuenta que alguien que puede redirigir su conexión ssh también puede redirigir una sesión de navegador web).

Si se ha conectado a este servidor anteriormente desde esta instalación de ssh, entonces el servidor se ha reconfigurado con una nueva clave o alguien está falsificando la identidad del servidor. Debido a la seriedad de un ataque de hombre en el medio, te está advirtiendo sobre la posibilidad.

De cualquier manera, tienes un canal cifrado seguro para alguien . Nadie sin la clave privada correspondiente a la huella digital 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40puede decodificar lo que envía.

La clave que utiliza para autenticarse no está relacionada ... no le gustaría enviar información de autenticación a un servidor fraudulento que podría robarla, por lo que no debe esperar ningún cambio dependiendo de si va a usar una frase de contraseña o clave privada para iniciar sesión. Simplemente no has llegado tan lejos en el proceso todavía.


Entonces, incluso si hay un tercero malintencionado, y rechazo el mensaje, ¿todo lo que voy a hacer es enviarle mi clave pública y aún así no podrá descifrar mis datos? Entonces, las únicas formas en que mis datos pueden verse comprometidos son si (1) mi clave privada está en peligro o (2) los servidores de bitbucket están en peligro o (3) mi cuenta de bitbucket está en peligro. Siempre y cuando limiten los intentos de inicio de sesión (lo que me sorprendería mucho si no lo hacen) realmente no hay muchas razones para ser paranoico en este momento, ¿eh?
Steven Lu

10
@ Steven: No le estás enviando tu clave pública, él ya la tiene. Lo que está haciendo es usar su clave privada para autenticar un desafío ... si él se conectó con el verdadero bitbucket.org afirmando ser usted, recibió el desafío real y usó ese desafío cuando lo desafió, entonces podría engañarlo enviándole una respuesta válida que luego utiliza para obtener acceso a su cuenta en el bitbucket.org real. Todavía no tiene su clave privada, por lo que no puede iniciar sesión en ningún momento futuro, ni a ningún otro recurso que la clave desbloquee, pero sí tiene una sesión de inicio de sesión.
Ben Voigt

Eso es lo que quise decir en mi respuesta cuando dije "no querría enviar información de autenticación a un servidor fraudulento".
Ben Voigt

2
"Si eres paranoico, verifica la suma de comprobación / huella digital de la clave usando un canal alternativo". Para los paranoicos (y para el registro), la huella digital de github está en help.github.com/articles/generating-ssh-keys y bitbucket's se menciona en confluence.atlassian.com/display/BITBUCKET/…
sundar

1
@BenVoigt Sí, entiendo que, paranoico, por supuesto, llegaría a esas páginas a través de una red diferente no relacionada, o tal vez volaría a la sede de Github y obtendría la huella digital en persona :)
Sundar

21

Digamos que conoce a alguien para intercambiar algunos secretos comerciales. Su asesor le dice que nunca antes ha conocido a esa persona y que puede ser un impostor. Además, para las próximas reuniones con él, su asesor ya no le avisará. Eso es lo que significa el mensaje. La persona es el servidor remoto y su asesor es el cliente ssh.

No creo que sea paranoico verificar la identidad de la persona antes de compartir secretos con ella. Por ejemplo, puede abrir una página web con una foto de ella y compararla con la cara que tiene delante. O revise su documento de identidad.

Para el servidor bitbucket, puede usar una computadora diferente y más confiable y obtener la imagen de su cara , y luego compararla con la que obtiene en la computadora que está usando ahora. Utilizar:

 ssh-keyscan -t rsa bitbucket.org | ssh-keygen -lv -f -

Si las caras coinciden, puede agregar la clave al archivo, por ejemplo ~/.ssh/known_hosts(ubicación estándar en muchas distribuciones de Linux) con:

ssh-keyscan -t rsa -H bitbucket.org >> ~/.ssh/known_hosts

y el cliente ssh no te avisará porque ya conoce su cara . Comparará las caras cada vez que te conectes. Eso es muy importante. En el caso de un impostor (por ejemplo, un ataque man-in-the-middle), el cliente ssh rechazará la conexión porque la cara habrá cambiado.


Esta respuesta es muy útil
010110110101

44
Esta debería ser la respuesta aceptada: ¡ ssh-keyscan -t rsa -H bitbucket.org >> ~/.ssh/known_hosts Gracias Ivan!
Rod

1
@ Rod: elegiría la respuesta aceptada en función de un comando que es totalmente innecesario (puede modificarlo known_hostssimplemente escribiendo "sí" en la advertencia original, como ya se muestra en la pregunta) y peligroso (la clave que agregó a su el archivo no es necesariamente el mismo que miró, ¡porque lo obtuvo dos veces!)?
Ben Voigt

@BenVoigt lo que proporciona esta solución es que escribir "sí" no es que esta solución sea totalmente programable. Supongo que la mayoría de las personas pueden descubrir cómo responder al "(sí / no)?" rápido. Encontré estas preguntas y respuestas mientras intentaba descubrir cómo resolver este problema sin intervención humana (para un script de configuración del servidor). En mi entusiasmo, supongo que no me di cuenta de que la pregunta del OP es un poco diferente a la mía, pero en mi opinión, esta sigue siendo la respuesta más útil / no obvia en el hilo.
Rod

@ Rod: No, no es útil. Bajar su seguridad es malo. Encontrar formas más rápidas de reducir su seguridad es exactamente lo contrario de útil.
Ben Voigt

5

Simplemente tuve que crear el known_hostsarchivo de texto en~/.ssh

sudo vim ~/.ssh/known_hosts
sudo chmod 777 ~/.ssh/known_hosts

Después de hacer esto, agregó el host y nunca volví a ver el mensaje.


No creo que eso realmente cambie nada. La advertencia se muestra cuando el servidor mismo ha cambiado. Por ejemplo, si aprovisiona una nueva máquina virtual a la que se está conectando por primera vez. Si tiene o no un known_hostsarchivo (con los permisos correctos) no impide que le pregunte sobre la autenticidad del nuevo servidor ... A menos que de alguna manera ya haya obtenido la firma de clave de pub para este servidor y la haya puesto en su known_hosts, cuál es la forma normal de saltear el cheque (aunque decir "sí" al cheque a menudo es más rápido para lograr lo mismo)
Steven Lu

Gracias. Había conocido_hosts, pero seguía recibiendo la advertencia. Solo tuve que cambiar los permisos en conocido_hosts para que se detengan las advertencias.
ArcaneDominion

66
Por favor no hagas esto. Puede ser un grave peligro para la seguridad. Su archivo de host solo debe poder ser escrito por usted. El segundo comando básicamente permite que cualquier persona en su computadora falsifique las identidades del servidor.
Stolz

"La advertencia se muestra cuando el servidor mismo ha cambiado". O cuando el servidor nunca ha sido visitado antes.
Rod

2

Hay otra manera fácil Simplemente toque un archivo "config" en /root/.ssh y agregue el parámetro StrictHostKeyChecking no La próxima vez que inicie sesión en un servidor, se agregará la clave rsa a known_hosts y no preguntará "yes" para confirmación de autenticidad


3
Esto no es recomendable. Es fácil pero no es la forma correcta de lidiar con la situación.
Vikas

1

Este mensaje es solo SSH diciéndole que nunca antes ha visto esta clave de host en particular, por lo que no puede verificar realmente que se está conectando al host que cree que es. Cuando dice "Sí", coloca la clave ssh en su archivo conocido_hosts, y luego en las conexiones posteriores comparará la clave que obtiene del host con la del archivo conocido_hosts.

Hubo un artículo relacionado sobre el desbordamiento de la pila que muestra cómo deshabilitar esta advertencia, https://stackoverflow.com/questions/3663895/ssh-the-authenticity-of-host-hostname-cant-be-established .


10
Pero no se recomienda deshabilitar la advertencia : está ahí para un propósito, proporcionando información de seguridad muy útil.
Rory Alsop

0

Además de las respuestas ya dadas (nunca se conectó a este host antes), también existe la posibilidad clara de que nunca se haya conectado DESDE el host actual antes (a ese host); esto es solo psicológicamente diferente; cree que se está conectando desde el host A (a B), mientras que realmente está intentando conectarse desde el host X (a B). Esto puede suceder, por ejemplo, cuando primero ssh-ed de A a X y luego desde la misma terminal intente ssh a B pensando que todavía está en A.


Me pregunto si usar el reenvío de agentes ssh también puede suprimir la advertencia si el host A sabe acerca de B pero X no, pero el reenvío de agentes se realiza entre A y X. La mayoría de los entornos (que proporcionan ssh) y las aplicaciones de terminal admiten el reenvío de agentes, ayuda reduzca la cantidad de claves ssh que debe administrar solo en sus dispositivos finales.
Steven Lu

0

En mi caso, la contraseña menos inicio de sesión no funcionaba debido a los permisos de mi directorio personal porque cambié la configuración predeterminada. Finalmente, esto es lo que funcionó para mí. mis permisos de directorio de inicio son

/ inicio / nombre de usuario

drwxr----x. 18 username     groupname  4096 May 11 11:52 username

/home/username/.ssh

268823097 drwx------   2 username groupname     29 May 11 11:53 .ssh

/home/username/.ssh/authorized_keys

-rw-r----- 1 username groupname 402 May 11 11:53 authorized_keys
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.