ssh: La autenticidad de 'host' de acogida no puede establecerse

Question

Cuando i ssh a una máquina, en algún momento me sale este aviso de error y se lleva a decir "sí" o "no". Esta causa algunos problemas cuando se ejecuta desde scripts que automáticamente ssh 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 forma automática decir "sí" o ignorar esto?

Answer 1

En función de su cliente SSH, se puede establecer la opción de StrictHostKeyChecking no está en la línea de comandos, y / o enviar la clave a un archivo known_hosts nulos. También puede establecer estas opciones en el archivo de configuración, ya sea para todos los hosts o para un determinado conjunto 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 el recurso que se está conectando ha sido suplantada por un atacante, que potencialmente podría jugar de nuevo la espalda del servidor de destino reto para usted, usted engañando al pensar que se va a conectar al recurso remoto mientras que en realidad se conectan a ese recurso con sus credenciales. Usted debe considerar cuidadosamente si eso es un riesgo apropiada para asumir antes de modificar su mecanismo de conexión para saltar HostKeyChecking.

de referencia.

Answer 2

vieja pregunta que merece una respuesta mejor.

Se puede prevenir la pronta interactiva sin desactivar 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

Se comprueba si la clave pública del servidor se encuentra en known_hosts. Si no es así, solicita la clave pública del servidor y lo añade a known_hosts.

De esta manera usted está expuesto a los 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 troncos o known_hosts para comprobar las huellas dactilares manualmente (a hacerse sólo una vez)

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 de host puede ser * para permitir el acceso sin restricciones a todas las direcciones IP.
• Editar /etc/ssh/ssh_config para la configuración global o ~/.ssh/config para la configuración específica de usuario.

http: // linuxcommando .blogspot.com / 2008/10 / cómo-a-disable-ssh-host-key-checking.html

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

Answer 4

Asegúrese de que ~/.ssh/known_hosts se puede escribir. El fijado por mí.

Answer 5

La mejor manera de hacer esto es utilizar 'BatchMode', además de 'StrictHostKeyChecking'. De esta manera, la secuencia de comandos aceptará un nuevo nombre de host y escribirla en el archivo known_hosts, pero no requerirá sí / no intervención.

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

Answer 6

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

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

conjunto de usuarios para your_login_user dice que esta configuración pertenece a your_login_user
StrictHostKeyChecking conjunto a no evitará el símbolo
IdentityFile es camino hacia la clave RSA

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

Answer 7

Esta advertencia es emitida por los elementos de seguridad, no desactive esta función.

Es sólo aparece una vez.

Si todavía aparece después de la segunda conexión, el problema está probablemente en la escritura en el fichero de known_hosts. En este caso también obtendrá el siguiente mensaje:

Failed to add the host to the list of known hosts 

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

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

Answer 8

Con referencia a la respuesta de Cori, he modificado y utilizado por debajo de comando, que está trabajando. 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 9

Haga esto -> chmod +w ~/.ssh/known_hosts. Esto añade el permiso de escritura en el archivo en ~/.ssh/known_hosts. Después de que el host remoto se añade al archivo known_hosts cuando se conecta a la próxima vez.

Answer 10

En general, este problema se produce cuando se está modificando las claves muy oftenly. Basado en el servidor que podría tomar algún tiempo para actualizar la nueva clave que ha generado y pegado en el servidor. Así que después de la generación de la clave y pegar en el servidor, espere 3 a 4 horas y luego tratar. El problema debe ser resuelto. Sucedió conmigo.

Answer 11

Lo ideal es que debe crear una autoridad de certificación autogestionada. Comenzar con la generación de un par de claves: ssh-keygen -f cert_signer

A continuación, 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

Reiniciar 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 host está firmado por la clave privada cert_signer.

A pesar de que esto requiere una configuración de una sola vez en el lado del cliente, puede confiar en varios servidores, incluyendo aquellos que no provisionada sin embargo (siempre y cuando usted se inscribe cada servidor, que es).

Para más detalles, véase esta página wiki .

Answer 12

Añadir estos a su / etc / ssh / ssh_config

Host *
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no

Answer 13

Ejecutar este en el servidor host que del tema premonición

chmod -R 700 ~/.ssh

Answer 14

Yo tenía el mismo error y quería llamar la atención sobre el hecho de que - como lo que acaba de ocurrir a mí -. Que sólo podría tener privilegios equivocadas
Estás haya configurado el directorio de .ssh ya sea como usuario normal o root y por lo tanto tiene que ser el usuario correcto. Cuando apareció este error, yo estaba root pero he configurado .ssh como usuario normal. Al salir root fijado a él.

Answer 15

resuelvo el tema que da a continuación de error escrito:
Error:
La autenticidad de acogida 'XXX.XXX.XXX' no puede ser establecida.
clave RSA de huellas digitales es 09: 6c: EF: cd: 55: c4: 4f: ss: 5a: 88: 46: 0a: a9: 27: 83: 89.

Solución:
1. Instalar cualquier herramienta openSSH.
2. Ejecutar comando ssh
3. se le pedirá hacer u anadir este anfitrión similares.    aceptar SÍ.
4. Este ordenador añadirá en la lista de hosts conocidos.
5. Ahora usted es capaz de conectar con este host.

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