ssh: no se puede establecer la autenticidad del host 'hostname'

Cuando hago un ssh a una máquina, en algún momento recibo esta advertencia de error y me pide que diga "sí" o "no". Esto causa algunos problemas cuando se ejecuta desde scripts que ssh 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 manera de decir automáticamente "sí" o ignorar esto?

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 conocido_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 el recurso al que se está conectando ha sido falsificado por un atacante, podrían volver a reproducir el desafío del servidor de destino, haciéndole creer que se está conectando al recurso remoto mientras de hecho se están conectando a ese recurso sus credenciales Debe considerar cuidadosamente si es un riesgo apropiado asumir antes de modificar su mecanismo de conexión para omitir HostKeyChecking.

Referencia .

Antigua pregunta que merece una mejor respuesta.

Puede evitar la solicitud interactiva sin deshabilitar StrictHostKeyChecking(lo cual 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 known_hosts.

De esta manera, está expuesto al ataque Man-In-The-Middle solo una vez, que puede ser mitigado por:

• asegurando que el script se conecta por primera vez a través de un canal seguro
• inspeccionar registros o conocido_hosts para verificar las huellas digitales manualmente (se debe hacer solo una vez)

Para deshabilitar (o controlar deshabilitar), 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 *permitir el acceso sin restricciones a todas las IP.
• Edite /etc/ssh/ssh_configpara la configuración global o ~/.ssh/configpara la configuración específica del usuario.

Ver http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html

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

Asegúrate de que ~/.ssh/known_hostsse pueda escribir. Eso me lo arregló.

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

ssh -o BatchMode=yes -o StrictHostKeyChecking=no user@server.example.com "uptime"

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 establecido en your_login_userdice que esta configuración pertenece a your_login_user
StrictHostKeyChecking establecido en no evitará el mensaje
IdentityFile es la ruta a la clave RSA

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

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, el problema probablemente se deba a la escritura en el known_hostsarchivo. En este caso, también recibirá el siguiente mensaje:

Failed to add the host to the list of known hosts 

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

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

Con referencia a la respuesta de Cori, lo modifiqué y usé el siguiente comando, que está funcionando. Sin exit, el comando restante en realidad estaba iniciando sesión en la máquina remota, lo que no quería en el script

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

Haz 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 known_hostsarchivo cuando se conecte a él la próxima vez.

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

Luego firme la clave de host pública 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, apunte el HostCertificatea 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 cert_signerclave pública confiará en cualquier servidor cuya clave de host pública esté firmada por la cert_signerclave privada.

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

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

Generalmente, este problema se produce cuando modifica las claves con mucha frecuencia. Según el 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

Agregue estos a su / etc / ssh / ssh_config

Host *
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no

Ejecute esto en el servidor host, es un problema de premonición

chmod -R 700 ~/.ssh

Tuve el mismo error y quería llamar la atención sobre el hecho de que, como me sucedió a mí, podría tener privilegios incorrectos.
Ha configurado su .sshdirectorio como regular o como rootusuario y, por lo tanto, debe ser el usuario correcto. Cuando apareció este error, estaba rootpero lo configuré .sshcomo usuario normal. Salir lo rootarregló.

Resuelvo el problema que da el siguiente error escrito:
Error:
no se puede establecer la autenticidad del host 'XXX.XXX.XXX'.
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. instale cualquier herramienta openSSH.
2. ejecute el comando ssh
3. le preguntará si agrega este host como. acepta SI.
4. Este host se agregará en la lista de hosts conocidos.
5. Ahora puede conectarse con este host.

Esta solución está funcionando ahora ......