comandos - problema ssh ansible conocido

clusvcadm

Question

Estoy ejecutando Ansible Playbook y funciona bien en una máquina.

En una máquina nueva cuando lo intento por primera vez, aparece el siguiente error.

17:04:34 PLAY [appservers] ************************************************************* 
17:04:34 
17:04:34 GATHERING FACTS *************************************************************** 
17:04:34 fatal: [server02.cit.product-ref.dev] => {''msg'': "FAILED: (22, ''Invalid argument'')", ''failed'': True}
17:04:34 fatal: [server01.cit.product-ref.dev] => {''msg'': "FAILED: (22, ''Invalid argument'')", ''failed'': True}
17:04:34 
17:04:34 TASK: [common | remove old ansible-tmp-*] ************************************* 
17:04:34 FATAL: no hosts matched or all hosts have already failed -- aborting
17:04:34 
17:04:34 
17:04:34 PLAY RECAP ******************************************************************** 
17:04:34            to retry, use: --limit @/var/lib/jenkins/site.retry
17:04:34 
17:04:34 server01.cit.product-ref.dev      : ok=0    changed=0    unreachable=1    failed=0   
17:04:34 server02.cit.product-ref.dev      : ok=0    changed=0    unreachable=1    failed=0   
17:04:34 
17:04:34 Build step ''Execute shell'' marked build as failure
17:04:34 Finished: FAILURE

Este error se puede resolver, si primero voy a la máquina de origen (desde donde estoy ejecutando el libro de juego de ansible) y manualmente ssh a la máquina de destino (como el usuario dado) e ingrese "sí" para la entrada del archivo conocido_hosts.

Ahora, si ejecuto el mismo libro de juego ansible por segunda vez, funciona sin error.

Por lo tanto, ¿cómo puedo suprimir la pregunta que da SSH al hacer la entrada ssh known_hosts por primera vez para un usuario determinado (carpeta ~ / .ssh, archivo known_hosts)?

Descubrí que puedo hacer esto si uso las siguientes entradas de configuración en el archivo ~ / .ssh / config .

~ / .ssh / config

# For vapp virtual machines
Host *
  StrictHostKeyChecking no
  UserKnownHostsFile=/dev/null
  User kobaloki
  LogLevel ERROR

es decir, si coloco el código anterior en el archivo ~ / .ssh / config del usuario de una máquina remota y pruebo el Playbook de Ansible por primera vez, no se me pedirá que ingrese "sí" y el Playbook se ejecutará con éxito (sin requerir el usuario para crear manualmente una entrada de archivo conocido desde el equipo de origen al equipo de destino / remoto).

Mis preguntas: 1. ¿Qué problemas de seguridad debo tener en cuenta si voy ~ / .ssh / config way 2. ¿Cómo puedo pasar la configuración (lo que hay en el archivo de configuración) como parámetros / opciones para poder acceder a la línea de comandos para que ¿se ejecutará por primera vez en una máquina nueva (sin preguntar / dependiendo de la entrada de archivo conocido_hosts en la máquina de origen para la máquina de destino?

Answer 1

Desactivar la verificación de la clave del host por completo es una mala idea desde el punto de vista de la seguridad, ya que te abre a los ataques del hombre en el medio.

Si puede asumir que la red actual no está comprometida (es decir, cuando ssh a la máquina por primera vez y se le presenta una clave, esa clave es en realidad de la máquina y no de un atacante), entonces puede usar ssh-keyscan y el módulo de shell para agregar las claves de los nuevos servidores a su archivo de hosts conocidos (edición: la respuesta de Stepan hace esto de una mejor manera):

- name: accept new ssh fingerprints
  shell: ssh-keyscan -H {{ item.public_ip }} >> ~/.ssh/known_hosts
  with_items: ec2.instances

(Demostrado aquí como lo encontraría después del aprovisionamiento de EC2 ).

Answer 2

Los documentos ansible tienen una sección sobre esto . Citando

Ansible 1.2.1 y posterior tienen habilitada la verificación de la clave del host por defecto.

Si se reinstala un host y tiene una clave diferente en ''known_hosts'', esto generará un mensaje de error hasta que se corrija. Si un host no está inicialmente en ''conocido_host'', esto resultará en una solicitud de confirmación de la clave, lo que resulta en una experiencia interactiva si se usa Ansible, por ejemplo, cron. Puede que no quieras esto.

Si comprende las implicaciones y desea deshabilitar este comportamiento, puede hacerlo editando /etc/ansible/ansible.cfg o ~ / .ansible.cfg:

[defaults]
host_key_checking = False

Alternativamente, esto puede ser establecido por una variable de entorno:

$ export ANSIBLE_HOST_KEY_CHECKING=False

También tenga en cuenta que la verificación de la clave del host en el modo paramiko es razonablemente lenta, por lo que también se recomienda cambiar a ''ssh'' al usar esta función.

Answer 3

No haría algo como este trabajo para preparar el archivo conocido_hosts:

ANSIBLE_HOST_KEY_CHECKING=false ansible all -m ping

¿Esto debería conectarse a cada host en el inventario, actualizando el archivo conocido_hosts para cada host sin tener que ingresar "sí" para cada indicador, y luego ejecuta el módulo "ping" en cada host?

Una prueba rápida (eliminar mi archivo known_hosts y luego ejecutar lo anterior, realizado en una instancia de Ubuntu 16.04) pareció llenar el archivo known_hosts con sus huellas dactilares actuales.

La solución de @Stepan Vavra no funcionó para mí porque estaba usando hosts con alias (estaba conectándome a direcciones IP internas que no tenían DNS disponible para ellos, así que quería nombres más descriptivos para referirme a cada host en el inventario y tener la variable ansible_host apunta a la IP real para cada uno). Ejecutar lo anterior fue mucho más simple y preparó mi archivo known_hosts sin tener que deshabilitar la comprobación de la clave del host en ansible o ssh.

Answer 4

Para actualizar el archivo known_hosts , terminé usando una combinación de ssh-keyscan (con la dig para resolver un nombre de host a la dirección IP) y el módulo ansible known_hosts siguiente manera: (nombre de archivo ssh-known_hosts.yml )

- name: Store known hosts of ''all'' the hosts in the inventory file
  hosts: localhost
  connection: local

  vars:
    ssh_known_hosts_command: "ssh-keyscan -T 10"
    ssh_known_hosts_file: "{{ lookup(''env'',''HOME'') + ''/.ssh/known_hosts'' }}"
    ssh_known_hosts: "{{ groups[''all''] }}"

  tasks:

  - name: For each host, scan for its ssh public key
    shell: "ssh-keyscan {{ item }},`dig +short {{ item }}`"
    with_items: "{{ ssh_known_hosts }}"
    register: ssh_known_host_results
    ignore_errors: yes

  - name: Add/update the public key in the ''{{ ssh_known_hosts_file }}''
    known_hosts:
      name: "{{ item.item }}"
      key: "{{ item.stdout }}"
      path: "{{ ssh_known_hosts_file }}"
    with_items: "{{ ssh_known_host_results.results }}"

Para ejecutar tal yml, haz

ANSIBLE_HOST_KEY_CHECKING=false ansible-playbook path/to/the/yml/above/ssh-known_hosts.yml

Como resultado, para cada host en el inventario , todos los algoritmos compatibles se agregarán / actualizarán en el archivo known_hosts bajo el nombre de host, registro de par de known_hosts ; como

atlanta1.my.com,10.0.5.2 ecdsa-sha2-nistp256 AAAAEjZHN ... NobYTIGgtbdv3K+w=
atlanta1.my.com,10.0.5.2 ssh-rsa AAAAB3NaC1y ... JTyWisGpFeRB+VTKQ7
atlanta1.my.com,10.0.5.2 ssh-ed25519 AAAAC3NaCZD ... UteryYr
denver8.my.com,10.2.13.3 ssh-rsa AAAAB3NFC2 ... 3tGDQDSfJD
...

(Siempre que el archivo de inventario se vea como:

[master]
atlanta1.my.com
atlanta2.my.com

[slave]
denver1.my.com
denver8.my.com

)

A diferencia de la respuesta de Xiong, esto manejaría adecuadamente el contenido del archivo known_hosts .

Este juego es especialmente útil si se usa un entorno virtualizado donde los hosts de destino se vuelven a crear imágenes (por lo tanto, las claves de pub ssh se cambian).

Answer 5

Siguiendo la respuesta correcta de @Stepan Vavra. Una versión más corta es:

- known_hosts:
    name: "{{ item }}"
    key: "{{ lookup(''pipe'', ''ssh-keyscan {{ item }},`dig +short {{ item }}`'') }}"
  with_items:
   - google.com
   - github.com

Answer 6

También puede establecer esto desde el nivel del sistema operativo del servidor. tendrá que configurar el archivo de configuración ssh para evitar que ssh compruebe:

Editar la ruta del archivo:

/etc/ssh/ssh_config

ahora descomenta la línea

StrictHostKeyChecking no

Guarda los cambios y eso es todo.