# SSH Keys

Cada playbook de Trellis utiliza un usuario SSH específico para conectarse a las máquinas remotas (o guest MV).

Esta página explica como configurar usuarios SSH para los playbooks server.yml and deploy.yml. Si estás buscando por opciones de configuración SSH generales, vea el README.md del rol sshd.

Si únicamente usted estará provisionando y corriendo el deploy, y su SSH public key se encuentra disponible en ~/.ssh/id_rsa.pub, no será necesario modificar la configuración predeterminada en users.

# El diccionario users

Mientras provisiona, server.yml creará los users definidos en group_vars/all/users.yml, asignándoles los groups y las public SSH keys. El ejemplo de abajo define un usuario único.

users:
  - name: username
    groups:
      - primary_group
      - other_group
    keys:
      - "{{ lookup('file', '/path/to/local/file') }}"
      - https://github.com/username.keys

Primero especifica el grupo primario del usuario en la lista de groups. Agregue las keys a cualquiera que necesite hacer conexiones SSH como ese usuario. server.yml puede lookup keys en archivos locales o traerlas desde URLs remotas. Este es un ejemplo de public keys alojadas en GitHub: https://github.com/swalkinshaw.keys

En caso que fuera necesario, puedes redefinir los users en cualquier archivo de entorno group_vars, sobreescribiendo la lista de users en group_vars/all/users.yml.

# server.yml: root o admin

Asumimos que al crear el servidor por primera vez ya ha agregado su SSH keys a la cuenta root. Digital Ocean incluirá estas cuando creas el droplet. Si no quieres utilizar una SSH key, deberás incluir la opción --ask-pass cada vez que ejecutas el playbook server.yml.

server.yml intentará conectarse al servidor como root. Si la conexión falla, server.yml intentará conectarse como el admin_user definido en group_vars/all/users.yml (predeterminado admin). Si el login root es deshabilitado en el servidor es muy importante que, el admin_user definido en la lista de users, tenga permisos sudo en primer lugar en la lista de grupos (vea la documentación sobre Seguridad). La definición predeterminada para el admin_user se muestra debajo.

users:
  - name: '{{ admin_user }}'
    groups:
      - sudo
    keys:
      - "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"
      # - https://github.com/username.keys

admin_user: admin

Notas

• Agregando sus SSH keys públicas al admin_user puedes permitir que tus colegas que ejecuten server.yml.
• Si tu proveedor de hosting ha deshabilitado el root pero permite el acceso a través, por ejemplo, ubuntu, especifique admin_user: ubuntu.
• Si deseas sobreescribir la selección dinámica de root o admin_user, prefiriendo indicar manualmente a Ansible sobre el usuario remoto, revise las notas en la sección precedencia de usuario remoto variable.

# deploy.yml: web

El playbook deploy.yml realiza un deploy de tu sitio mientras se conecta como el web_user (predefinido como web), debido a que este usuario poseé archivos en el root, el destino del deploy. El web_group debe ubicarse primero en la lista de grupos para el web_user. La definición predeterminada para el web_user se muestra abajo.

web_user: web
web_group: www-data
⋮
users:
  - name: "{{ web_user }}"
    groups:
      - "{{ web_group }}"
    keys:
      - "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"
      # - https://github.com/username.keys

• Agregando sus SSH keys públicas al web_user puedes permitir que tus colegas que ejecuten deploy.yml. Vea el ejemplo debajo.

# Ejemplo users

Este ejemplo debajo agrega SSH keys de usuarios Github swalkinshaw y retlehs a ~/.ssh/authorized_keys para admin_user. Esto les permite a swalkinshaw y retlehs ejecutar server.yml para provisionar los servidores. Este ejemplo incluye sus keys, y las keys del usuario de Github austinpray a web_user. Esto les permite ejecutar deploy.yml para realizar deploys de los sitios a cada uno de ellos.

users:
  - name: '{{ web_user }}'
    groups:
      - '{{ web_group }}'
    keys:
      - https://github.com/swalkinshaw.keys
      - https://github.com/retlehs.keys
      - https://github.com/austinpray.keys
  - name: '{{ admin_user }}'
    groups:
      - sudo
    keys:
      - https://github.com/swalkinshaw.keys
      - https://github.com/retlehs.keys
  - name: otro_usuario
    groups:
      - algun_grupo
      - algun_otro_grupo
    keys:
      - https://github.com/swalkinshaw.keys

El ejemplo de arriba también muestra la opción de crear otro_usuario cuyo grupo primario es algun_grupo, pero que también se encuentra en algun_otro_grupo, y contiene las SSH keys públicas para swalkinshaw.

Nota

• Eliminando las keys y re-provisionando el servidor no elimina las keys en el archivo authorized_keys.

# Clonando un repo remoto utilizando SSH agent forwarding

Todas las conexiones SSH dicutidas arriba ocurren con Trellis conectándose desde su máquina local al servidor. Es un tipo de conexión distinta, sin embargo, cuando Trellis clona un servidor remoto privado mientras realiza el deploy. En este caso, tu servidor remoto está habilitado para hacer un forward de tus credenciales SSH locales al repo remoto para autorizar la conexión.

El archivo ansible.cfg de Trellis habilita este SSH agent forwarding con ssh_args = -o ForwardAgent=yes. No deberías necesitar auth tokens o keys privadas para el web_user. Si tienes inconvenientes clonando un repo remoto mientras realizas el deploy, mira Utilizando SSH agent forwarding para consejos y resolución de problemas.

# Usuarios macOS/OS X

Recuerden importar el password SSH key en la Keychain ejecutando:

ssh-add -K