ssh: La autenticidad del host 'nombre de host' no se puede establecer

Question

Cuando me conecto a 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 una manera de decir de forma automática "sí" o ignorar esto?

Answer 1

Según 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 notas @IanDunn, existen riesgos de seguridad para 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 2

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 3

Para desactivar (o desactivación de control), añadir las siguientes líneas al principio del /etc/ssh/ssh_config ...

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

Opciones:

• La subred huésped puede ser * para permitir el acceso sin restricciones a todos los IP.
• Editar /etc/ssh/ssh_config para la configuración global o ~/.ssh/config para la configuración específica del usuario.

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

pregunta similares en superuser.com - veo https://superuser.com/a/628801/55163

Answer 4

resuelvo el tema que da a continuación de error escrito:
error:
La autenticidad de acogida '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. instale cualquier herramienta openSSH.
2. ejecute el comando ssh
3. le preguntará si desea agregar este host como. acepta SÍ.
4.Este host agregará en la lista de hosts conocidos.
5. Ahora puede conectarse con este host.

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

Answer 5

Asegúrese ~/.ssh/known_hosts se puede escribir. Eso lo solucionó para mí.

Answer 6

La mejor manera de hacerlo es utilizar '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 user@server.example.com "uptime" 

Answer 7

Pregunta anterior que merece una respuesta mejor.

Puede evitar la solicitud interactiva sin deshabilitar StrictHostKeyChecking (que es inseguro).

Incorporar la siguiente lógica en la secuencia de comandos:

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

comprueba si la clave pública del servidor se encuentra en known_hosts. De lo contrario, solicita la clave pública del servidor y la agrega al known_hosts.

De esta manera usted está expuesto a ataques man-in-the-middle una sola vez, lo que puede ser mitigado por:

• asegurar que el script se conecta por primera vez por un canal seguro
• inspección de registros o known_hosts para comprobar las huellas dactilares de forma manual (que se realiza una sola vez)

Answer 8

Editar archivo de su configuración normalmente se encuentra en '~/.ssh/config', ya comienzos de los archivos, añadir las siguientes líneas

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

usuario establecer a your_login_user dice que esta configuración pertenece a your_login_user
StrictHostKeyChecking establece en no evitará el símbolo
IdentityFile es camino hacia la clave RSA

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

Answer 9

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

Se muestra solo una vez.

Si aún aparece después de la segunda conexión, es probable que el problema se encuentre al escribir en el archivo known_hosts. En este caso también obtendrá el siguiente mensaje:

Failed to add the host to the list of known hosts 

Usted puede solucionarlo cambiando propietario de cambiar los permisos del archivo para ser su usuario puede escribir.

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

Answer 10

hacer esto -> chmod + w ~/.ssh/known_hosts Esto añade permiso de escritura en el 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 11

Con referencia a la respuesta de Cori, la modifiqué y usé debajo del comando, que está funcionando. Sin exit, comando restante fue de hecho el registro en la máquina remota, que no quería en escritura

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

Answer 12

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

Luego de firmar la clave pública host 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 HostCertificate a este archivo : HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

Reinicie el servicio sshd: service sshd restart

A continuación, en el cliente SSH, añada lo siguiente a ~/.ssh/known_hosts: @cert-authority *.example.com ssh-rsa AAAAB3Nz...cYwy+1Y2u/

El 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 obtener más información, consulte this wiki page.