2012-05-05 23:39:28 +0000 2012-05-05 23:39:28 +0000
84
84

SSH: La autenticidad del host no puede ser establecida

¿Qué significa este mensaje? ¿Es un problema potencial? ¿No es el canal seguro?

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

Estoy acostumbrado a ver este mensaje cuando uso SSH en el pasado: Siempre ingresé mi login con una contraseña de la manera normal, y me sentí bien por ello porque no estaba haciendo uso de claves privadas/públicas (lo cual es mucho más seguro que una contraseña corta). Pero esta vez he configurado una clave pública con ssh para mi conexión a bitbucket pero aún así recibí el mensaje. Soy consciente de que el mensaje de la frase de contraseña al final es una medida de seguridad diferente y suplementaria, para el descifrado de la clave privada.

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

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':
Fuente

Respuestas (7)

71
71
71
2012-05-06 00:23:59 +0000

Te está diciendo que nunca antes te habías conectado a este servidor. Si esperabas eso, es perfectamente normal. Si estás paranoico, verifica la suma de comprobación/huella de la llave usando un canal alternativo. (Pero ten en cuenta que alguien que puede redirigir tu conexión ssh también puede redirigir una sesión de navegador web)

Si te has conectado a este servidor antes desde esta instalación de ssh, entonces o bien el servidor ha sido reconfigurado con una nueva clave, o alguien está falseando la identidad del servidor. Debido a la seriedad de un ataque de hombre en el medio, te advierte sobre la posibilidad.

De cualquier manera, tienes un canal seguro encriptado a 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:40 puede decodificar lo que envías.

La clave que usas para autentificarte no está relacionada… no querrás enviar información de autenticación a un servidor fraudulento que podría robarla, por lo que no debes esperar ningún cambio dependiendo de si vas a usar una frase de contraseña o una clave privada para iniciar sesión. Simplemente no has llegado tan lejos en el proceso todavía.
Fuente
23
23
23
2016-08-10 11:42:38 +0000

Digamos que te encuentras con alguien para intercambiar algunos secretos de negocios. Su asesor le dice que nunca ha conocido a esa persona antes, y que puede ser un impostor. Además, para los próximos encuentros con él, su consejero no le va a advertir más. Eso es lo que significa el mensaje. La persona es el servidor remoto, y tu asesor es el cliente ssh.

No creo que sea paranoico comprobar dos veces la identidad de la persona antes de compartir secretos con ella. Por ejemplo, podrías abrir una página web con una foto de ella y compararla con la cara que tienes delante. O comprobar su tarjeta de identidad.

Para el servidor de bitbucket, podrías usar un ordenador diferente y más fiable y obtener la fotografía de su cara de él, y luego compararla con la que obtienes en el ordenador que estás usando ahora. Usa: 

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

Si las caras coinciden, puedes añadir 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 de un hombre en el medio), el cliente ssh rechazará la conexión porque la cara habrá cambiado.
Fuente
5
5
5
2014-07-16 15:44:43 +0000

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

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

Después de hacer esto, añadió el anfitrión y no volví a ver el mensaje.
Fuente
2
2
2
2014-12-16 08:23:53 +0000

Hay otra manera fácil Simplemente toque un archivo de “configuración” en /root/.ssh y agregue el parámetro StrictHostKeyChecking no La próxima vez que ingrese a un servidor, la clave rsa se agregará a los hosts conocidos y no pedirá un “sí” para confirmar la autenticidad.
Fuente
1
1
1
2012-05-05 23:52:02 +0000

Este mensaje es sólo SSH diciéndote que nunca antes ha visto esta clave de host en particular, por lo que no es capaz de verificar realmente que te estás conectando al host que crees que eres. Cuando dices “Sí” pone la clave ssh en tu archivo de hosts conocidos, y luego en las conexiones subsecuentes comparará la clave que obtiene del host con la del archivo de hosts conocidos.

Hubo un artículo relacionado sobre el desbordamiento de la pila que mostraba cómo desactivar esta advertencia, https://stackoverflow.com/questions/3663895/ssh-the-authenticity-of-host-hostname-cant-be-established .
Fuente
0
0
0
2017-11-04 13:51:11 +0000

Aparte de las respuestas ya dadas (nunca antes se ha conectado a este host), también existe la clara posibilidad de que nunca antes se haya conectado DESDE el host actual (a ese host); esto es sólo psicológicamente diferente; usted piensa que se está conectando desde el host A (a B), mientras que en realidad está tratando de conectarse desde el host X (a B). Esto puede ocurrir, por ejemplo, cuando primero ssh-ed de A a X y luego desde el mismo terminal intentas ssh a B pensando que todavía estás en A.
Fuente
0
0
0
2018-05-11 11:03:59 +0000

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

/home/nombre de usuario 

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

/home/nombre de usuario/.ssh 

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

/home/nombre de usuario/.ssh/authorized_keys 

-rw-r----- 1 username groupname 402 May 11 11:53 authorized_keys
Fuente