keys - ssh: la autenticidad del host ''nombre de host'' no se puede establecer

ssh keygen list keys

Question

Cuando uso ssh en una máquina, en algún momento aparece esta advertencia de error y me pide que diga "sí" o "no". Esto causa algunos problemas cuando se ejecuta desde scripts que se transfieren automáticamente a otras máquinas.

Mensaje de advertencia:

The authenticity of host ''<host>'' can''t be established.
ECDSA key fingerprint is    SHA256:TER0dEslggzS/BROmiE/s70WqcYy6bk52fs+MLTIptM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ''pc'' (ECDSA) to the list of known hosts.

¿Hay alguna forma de decir "sí" automáticamente o ignorar esto?

Answer 1

Asegúrese de que ~/.ssh/known_hosts sea ​​escribible. Eso lo solucionó para mí.

Answer 2

Con referencia a la respuesta de Cori, la modifiqué y usé debajo del comando, que está funcionando. Sin exit , el comando restante se estaba conectando a la máquina remota, lo que no quería en la secuencia de comandos

ssh -o StrictHostKeyChecking=no user@ip_of_remote_machine "exit"

Answer 3

Dependiendo de su cliente ssh, puede establecer la opción StrictHostKeyChecking en no en la línea de comando y / o enviar la clave a un archivo nulo known_hosts. También puede establecer estas opciones en su archivo de configuración, ya sea para todos los hosts o para un conjunto determinado de direcciones IP o nombres de host.

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

EDITAR

Como señala @IanDunn, existen riesgos de seguridad al hacer esto. Si un atacante ha falsificado el recurso al que se está conectando, podrían volver a reproducir el desafío del servidor de destino, engañándolo y haciéndole creer que se está conectando al recurso remoto, mientras que de hecho se están conectando a ese recurso con tus credenciales Debe considerar cuidadosamente si ese es un riesgo apropiado para asumir antes de alterar su mecanismo de conexión para omitir HostKeyChecking.

Reference .

Answer 4

Edite su archivo de configuración normalmente ubicado en ''~ / .ssh / config'', y al comienzo del archivo, agregue las líneas a continuación

Host *
    User                   your_login_user
    StrictHostKeyChecking  no
    IdentityFile          ~/my_path/id_rsa.pub

El usuario configurado en your_login_user dice que esta configuración pertenece a your_login_user
StrictHostKeyChecking establecido en no evitará el aviso
IdentityFile es la ruta a la clave RSA

Esto funciona para mí y mis guiones, buena suerte para ti.

Answer 5

En general, este problema se produce cuando modifica las claves muy a menudo. En función del servidor, puede llevar algún tiempo actualizar la nueva clave que ha generado y pegado en el servidor. Entonces, después de generar la clave y pegar en el servidor, espere de 3 a 4 horas y luego intente. El problema debe ser resuelto. Sucedió conmigo.

Answer 6

Haga esto -> chmod + w ~ / .ssh / known_hosts Esto agrega permiso de escritura al archivo en ~ / .ssh / known_hosts. Después de eso, el host remoto se agregará al archivo known_hosts cuando se conecte a él la próxima vez.

Answer 7

Idealmente, debe crear una autoridad de certificación autogestionada. Comience con la generación de un par de claves: ssh-keygen -f cert_signer

A continuación, firme la clave de host público de cada servidor: ssh-keygen -s cert_signer -I cert_signer -h -n www.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub

Esto genera una clave de host pública firmada: /etc/ssh/ssh_host_rsa_key-cert.pub

En /etc/ssh/sshd_config , HostCertificate el HostCertificate a este archivo: HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

Reinicie el servicio sshd: service sshd restart

Luego, en el cliente SSH, agregue lo siguiente a ~/.ssh/known_hosts : @cert-authority *.example.com ssh-rsa AAAAB3Nz...cYwy+1Y2u/

Lo anterior contiene:

• @cert-authority
• El dominio *.example.com
• El contenido completo de la clave pública cert_signer.pub

La clave pública cert_signer confiará en cualquier servidor cuya clave pública de host esté firmada por la clave privada cert_signer .

Aunque esto requiere una configuración única en el lado del cliente, puede confiar en varios servidores, incluidos aquellos que aún no se han aprovisionado (siempre y cuando firme cada servidor, eso es).

Para más detalles, mira esta página wiki .

Answer 8

La mejor manera de hacerlo es usar ''BatchMode'' además de ''StrictHostKeyChecking''. De esta forma, su script aceptará un nuevo nombre de host y lo escribirá en el archivo known_hosts, pero no requerirá intervención de sí / no.

ssh -o BatchMode=yes -o StrictHostKeyChecking=no [email protected] "uptime"

Answer 9

Para desactivar (o deshabilitar el control), agregue las siguientes líneas al comienzo de /etc/ssh/ssh_config ...

Host 192.168.0.*
   StrictHostKeyChecking=no
   UserKnownHostsFile=/dev/null

Opciones:

• La subred del host puede ser * para permitir el acceso irrestricto a todas las direcciones IP.
• Edite /etc/ssh/ssh_config para la configuración global o ~/.ssh/config para la configuración específica del usuario.

Ver Reference

Pregunta similar en superuser.com - ver https://superuser.com/a/628801/55163

Answer 10

Resuelvo el problema que da el siguiente error por escrito:
Error:
La autenticidad del host ''XXX.XXX.XXX'' no se puede establecer.
La huella digital de la clave RSA es 09: 6c: ef: cd: 55: c4: 4f: ss: 5a: 88: 46: 0a: a9: 27: 83: 89.

Solución:
1. instala cualquier herramienta openSSH.
2. ejecuta el comando ssh
3. Te preguntará por qué agregas este host. acepta SÍ.
4. Este host agregará en la lista de hosts conocidos.
5. Ahora puede conectarse con este host.

Esta solución está funcionando ahora ...

Answer 11

Una vieja pregunta que merece una mejor respuesta.

Puede evitar el aviso interactivo sin deshabilitar StrictHostKeyChecking (que es inseguro).

Incorpora la siguiente lógica en tu script:

if [ -z `ssh-keygen -F $IP` ]; then
  ssh-keyscan -H $IP >> ~/.ssh/known_hosts
fi

Comprueba si la clave pública del servidor está en known_hosts . Si no, solicita una clave pública del servidor y la agrega a known_hosts .

De esta forma estás expuesto al ataque Man-In-The-Middle solo una vez, lo que puede mitigarse con:

• asegurando que el script se conecta por primera vez a través de un canal seguro
• inspección de registros o known_hosts para verificar las huellas dactilares manualmente (solo se debe hacer una vez)

Answer 12

Esta advertencia se emite debido a las características de seguridad, no deshabilite esta característica.

Solo se muestra una vez.

Si aún aparece después de la segunda conexión, probablemente el problema esté en escribir en el archivo known_hosts . En este caso, también recibirá el siguiente mensaje:

Failed to add the host to the list of known hosts 

Puede solucionarlo cambiando de propietario al cambiar los permisos del archivo para que el usuario pueda escribirlo.

sudo chown -v $USER ~/.ssh/known_hosts