git - enable ssh agent

Reenvío de agente SSH con Ansible

Question

Estoy usando Ansible 1.5.3 y Git con reenvío de agente ssh ( https://help.github.com/articles/using-ssh-agent-forwarding ). Puedo iniciar sesión en el servidor que estoy administrando con Ansible y probar que mi conexión a git está configurada correctamente:

ubuntu@test:~$ ssh -T [email protected]
Hi gituser! You''ve successfully authenticated, but GitHub does not provide shell access.

También puedo clonar y actualizar uno de mis repos usando esta cuenta para que mi configuración de git se vea bien y use ssh forwarding cuando inicio sesión en mi servidor directamente a través de ssh.

El problema: cuando intento la misma prueba que se muestra arriba utilizando el módulo de comando Ansible. Falla con "Permiso denegado". Parte de la salida de Ansible (con registro detallado) se ve así:

failed: [xxx.xxxxx.com] => {"changed": true, "cmd": ["ssh", "-T", "[email protected]"], "delta": "0:00:00.585481", "end": "2014-06-09 14:11:37.410907", "rc": 255, "start": "2014-06-09 14:11:36.825426"}
stderr: Permission denied (publickey).

Aquí está el libro de jugadas simple que ejecuta este comando:

- hosts: webservers
sudo: yes
remote_user: ubuntu
tasks:
- name: Test that git ssh connection is working.
command: ssh -T [email protected]

La pregunta: ¿por qué todo funciona correctamente cuando inicio sesión manualmente a través de ssh y ejecuto el comando pero fallo cuando el mismo comando se ejecuta como el mismo usuario a través de Ansible?

Voy a publicar la respuesta en breve si nadie más me golpea. Aunque estoy usando git para demostrar el problema, podría ocurrir con cualquier módulo que dependa del reenvío del agente ssh. No es específico de Ansible, pero sospecho que muchos primero encontrarán el problema en este escenario.

Answer 1

Aquí hay algunas respuestas parciales muy útiles, pero después de toparme con este tema varias veces, creo que una descripción general sería útil.

En primer lugar, debe asegurarse de que el reenvío de agente SSH esté habilitado al conectarse desde su cliente que ejecuta Ansible a la máquina de destino. Incluso con transport=smart , el reenvío de agente SSH puede no habilitarse automáticamente, dependiendo de la configuración SSH de su cliente. Para asegurarse de que sea así, puede actualizar su ~/.ansible.cfg para incluir esta sección:

[ssh_connection]
ssh_args=-o ControlMaster=auto -o ControlPersist=60s -o ControlPath=/tmp/ansible-ssh-%h-%p-%r -o ForwardAgent=yes

A continuación, es probable que tenga que lidiar con el hecho de que become: yes (y become_user: root ) generalmente deshabilitará el reenvío del agente porque la variable de entorno SSH_AUTH_SOCK se restablece. (Me parece sorprendente que Ansible parezca suponer que las personas usarán SSH como root, ya que eso imposibilita cualquier auditoría útil). Hay algunas maneras de lidiar con esto. A partir de Ansible 2.2, el enfoque más fácil es preservar el entorno (completo) al usar sudo especificando el indicador -E :

become_flags: "-E"

Sin embargo, esto puede tener efectos secundarios no deseados al preservar variables como PATH . El enfoque más limpio es conservar solo SSH_AUTH_SOCK incluyéndolo en env_keep en su /etc/sudoers :

Defaults env_keep += "SSH_AUTH_SOCK"

Para hacer esto con Ansible:

- name: enable SSH forwarding for sudo
lineinfile:
dest: /etc/sudoers
insertafter: ''^#?/s*Defaults/s+env_keep/b''
line: ''Defaults env_keep += "SSH_AUTH_SOCK"''

Esta tarea de libro de jugadas es un poco más conservadora que otras sugeridas, ya que agrega esto después de cualquier otra configuración predeterminada de env_keep (o al final del archivo, si no se encuentra ninguna), sin cambiar ninguna configuración env_keep existente o asumiendo que SSH_AUTH_SOCK es ya presente.

Answer 2

El problema se resuelve eliminando esta línea del libro de jugadas:

sudo: yes

Cuando sudo se ejecuta en el host remoto, las variables de entorno establecidas por ssh durante el inicio de sesión ya no están disponibles. En particular, SSH_AUTH_SOCK, que "identifica la ruta de un socket de dominio UNIX utilizado para comunicarse con el agente" ya no está visible, por lo que el reenvío de agente ssh no funciona.

Evitar sudo cuando no lo necesita es una forma de evitar el problema. Otra forma es asegurar que SSH_AUTH_SOCK permanezca durante su sesión de sudo creando un archivo sudoers:

/etc/sudoers:
Defaults env_keep += "SSH_AUTH_SOCK"

Answer 3

Otra respuesta a su pregunta (con la excepción de que estoy usando Ansible 1.9) podría ser la siguiente:

Es posible que desee verificar su /etc/ansible/ansible.cfg (u otras tres ubicaciones posibles donde se pueden anular las configuraciones) para transport=smart tal como se recomienda en los documentos ansible . La mía había transport=paramiko en algún momento durante un intento de instalación anterior, lo que impedía que mi máquina de control utilizara OpenSSH y, por lo tanto, el reenvío de agentes. Este es probablemente un caso de borde masivo, pero ¿quién sabe? ¡Podría ser usted!

Aunque no -o ForwardAgent=yes fuera necesario para mi configuración, debería tener en cuenta que otros han mencionado que debe agregar -o ForwardAgent=yes a su configuración de ssh_args en el mismo archivo, de esta forma:

[ssh_connection]
ssh_args=-o ForwardAgent=yes

Solo lo menciono aquí por el bien de lo completo.

Answer 4

Para ampliar la respuesta de @ j.freckle, la forma más fácil de cambiar el archivo sudoers es:

- name: Add ssh agent line to sudoers
lineinfile:
dest: /etc/sudoers
state: present
regexp: SSH_AUTH_SOCK
line: Defaults env_keep += "SSH_AUTH_SOCK"