Tutoriales

Aumento de privilegios y autenticación SSH de Ansible

En este artículo, nos centraremos en dos conceptos importantes de Ansible. El primer concepto es cómo funciona la autenticación basada en claves y contraseñas SSH en Ansible. El segundo concepto es cómo escalar los privilegios al usar libros de jugadas y comandos ad hoc.

Tengo una configuración de laboratorio de tres nodos con VirtualBox y Vagrant ejecutando una máquina Ubuntu 20.04 LTS. Hay un artículo detallado sobre la configuración del laboratorio que puede leer en el siguiente enlace.

Autenticación basada en claves en Ansible

Lo primero que debe comprender al aprender ansible es cómo ocurre la comunicación entre el controlador y los nodos administrados. Usos de Ansible protocolo SSH Conéctese a nodos administrados y ejecute tareas.

Cada vez que ejecuta un libro de jugadas o un comando ad hoc, debe proporcionar la contraseña de SSH para que ansible se autentique en el nodo administrado a través de SSH.

Para eliminar esto, se recomienda crear un par de claves SSH y compartir la clave pública con todos los nodos para que ansible pueda comunicarse usando este par de claves.

Creé dos llamados primera_clave y segunda_clave Utilice el siguiente script para demostrarlo.

Crear un create_keypair.sh Están los siguientes.

#!/usr/bin/env bash

# THIS SCRIPT WILL CREATE SSH KEY PAIR AND DISTRIBUTE ACROSS ALL NODES

read -p "Enter the name for the key : " KEY_NAME
ssh-keygen -b 2048 -t rsa -f /home/vagrant/.ssh/${KEY_NAME} -q -N ""

# LOOPING THROUGH AND DISTRIBUTING THE KEY

for val in controller managed1 managed2; do
    echo "-------------------- COPYING KEY TO ${val^^} NODE ------------------------------"
    sshpass -p 'vagrant' ssh-copy-id -f -i /home/vagrant/.ssh/${KEY_NAME}.pub -o "StrictHostKeyChecking=no" [email protected]$val
done

Otorgue permiso de ejecución al script y ejecútelo.

$ chmod +x path/to/create_keypair.sh
$ ./create_keypair.sh

He creado este script para la configuración de mi laboratorio. Puede editar la sección de bucle for y agregar su nombre de nodo administrado en consecuencia.

$ tree .ssh/
.ssh/
├── authorized_keys
├── first_key
├── first_key.pub
├── known_hosts
├── second_key
└── second_key.pub

Cuando crea una clave con un nombre diferente al predeterminado (id_rsa), ssh intentará encontrar el nombre de clave predeterminado y, si no lo encuentra, solicitará una autenticación basada en contraseña.

debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/vagrant/.ssh/id_rsa
debug1: Trying private key: /home/vagrant/.ssh/id_dsa
debug1: Trying private key: /home/vagrant/.ssh/id_ecdsa
debug1: Trying private key: /home/vagrant/.ssh/id_ecdsa_sk
debug1: Trying private key: /home/vagrant/.ssh/id_ed25519
debug1: Trying private key: /home/vagrant/.ssh/id_ed25519_sk
debug1: Trying private key: /home/vagrant/.ssh/id_xmss
debug1: Next authentication method: password
[email protected]'s password:

En este caso tienes que usar -i bandera.

$ ssh -v -i /home/vagrant/.ssh/first_key [email protected]

Cuando ejecuta un comando ad hoc o un libro de jugadas, puede usar --key-file o --private-key etiquetar y pasar el archivo de clave privada como parámetro. En el siguiente ejemplo, puede ver que me comuniqué con éxito con el nodo administrado usando dos claves (first_key y second_key).

# USING --key-file FLAG

$ ansible managed1 -m ping --key-file /home/vagrant/.ssh/second_key

managed1 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}
# USING --private-key FLAG

$ ansible managed1 -m ping --private-key /home/vagrant/.ssh/first_key

managed1 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

También puede agregar parámetros»private_key_file» en el interior ansible.cfg Un archivo de configuración que se aplicará a los comandos ad hoc y todas las tareas del libro de jugadas.

$ vim ansible.cfg

Agregue las siguientes líneas:

Private_key_file = /home/vagrant/.ssh/first_key

reemplazar /home/vagrant/.ssh/first_key Usa los tuyos.

archivo de clave privada

También puedes agregar «ansible_ssh_clave_privada» Los parámetros en el archivo de inventario tendrán prioridad sobre ansible.cfg documento. A continuación se muestra cómo mi inventario ahora está configurado.nodo Alojamiento 1 utilizará «Primera clave» y Alojamiento 2 utilizará «Segunda clave».

[ubuntu1]
managed1 ansible_ssh_private_key_file=/home/vagrant/.ssh/first_key

[ubuntu2]
managed2 ansible_ssh_private_key_file=/home/vagrant/.ssh/second_key

Ahora, si ejecuta el comando adhoc o el libro de jugadas nuevamente, puede ver que ambas claves se autenticarán con éxito. Puede aumentar la verbosidad para comprobar que se utilizan las claves adecuadas en función de nuestra entrada.

$ ansible -vvv all -m ping
par de claves diferente
par de claves diferente

Ahora debería comprender bien cómo funciona la autenticación basada en claves en ansible. Al agregar parámetros en diferentes archivos, es importante comprender la prioridad.Las opciones de la línea de comandos tienen mayor prioridad, seguidas de los archivos de manifiesto y ansible.cfg archivo de configuración.

Autenticación basada en contraseña SSH en Ansible

Cuando ejecuta cualquier tarea, ansible usará el usuario actual en el nodo del controlador para comunicarse con el nodo administrado a través de SSH. Puede usar el módulo de shell y ejecutar «whoamiEl comando «autentica el nombre de usuario en el nodo administrado. En mi caso, el nombre de usuario es «vagabundo»El usuario .vagrant se está autenticando con la clave que configuré en la sección anterior.

$ whoami
vagrant
$ ansible all -m shell -a "whoami"
managed2 | CHANGED | rc=0 >>
vagrant
managed1 | CHANGED | rc=0 >>
vagrant

Si desea conectarse al nodo administrado como un usuario diferente, puede usar --u o --user etiquetar y pasar el nombre de usuario como parámetro. Si ve la imagen a continuación, estoy tratando de usar el usuario «karthick», que no tiene configuración de claves SSH ni claves distribuidas a los nodos administrados, por lo que la conexión falla.

$ ansible all -m shell -a "whoami" -u karthick
$ ansible all -m shell -a "whoami" --user karthick
error de conexión
error de conexión

Para usar la autenticación basada en contraseña, puede usar -k o --ask-pass bandera. Le pedirá que ingrese la contraseña SSH del usuario (karthick). Asegúrese de que la contraseña del usuario sea la misma en todos los nodos.

$ ansible all -m shell -a "whoami" -u karthick -k
$ ansible all -m shell -a "whoami" -u karthick --ask-pass
Solicitud de contraseña SSH
Solicitud de contraseña SSH

También puede almacenar la contraseña en un archivo y pasar el nombre del archivo como un parámetro para --connection-password-file o --conn-pass-file bandera. Esta no es la forma recomendada porque está almacenando la contraseña en un archivo de texto sin formato. Puede usar ansible Vault para cifrar archivos de contraseña, pero ese es un tema aparte para el debate.

$ ansible all -m shell -a "whoami" -u karthick --connection-password-file pass.txt
$ ansible all -m shell -a "whoami" -u karthick --conn-pass-file pass.txt

También puede pasar el nombre de usuario y la contraseña como parámetros en el archivo de manifiesto. Nuevamente, esta no es la mejor manera de almacenar contraseñas. Así es como está configurado mi archivo de inventario.

[ubuntu1]
managed1 ansible_ssh_private_key_file=/home/vagrant/.ssh/first_key ansible_user=vagrant

[ubuntu2]
managed2 ansible_user=karthick ansible_ssh_pass=password
$ ansible all -m shell -a "whoami" -u karthick

managed1 | CHANGED | rc=0 >>
vagrant
managed2 | CHANGED | rc=0 >>
karthick

Cuidado: Puede que esté ejecutando el ejemplo con un comando ad hoc, pero las mismas banderas se aplican al libro de jugadas.

Escalada de privilegios en Ansible

A veces, sus tareas requieren privilegios elevados (root) para ejecutarse correctamente. Por ejemplo, la gestión de paquetes.Solo puede instalar, eliminar o actualizar paquetes como root usuario o con sudo privilegio.

Cuando ejecuta el indicador de ayuda con ansible o ansible-playbook, encontrará la sección de escalada de privilegios como se muestra en la imagen.

$ ansible --help
$ ansible-playbook --help
Opciones de escalada de privilegios
Opciones de escalada de privilegios

cuando quieras ejecutar cualquier tarea root privilegios, debe usar -b o --become bandera.

$ ansible ubuntu1 -m service -a "name=sshd state=restarted" -b

managed1 | CHANGED => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": true,
    "name": "sshd",
    "state": "started",

por defecto, sudo Se utilizará como un método de escalada de privilegios.Puede cambiar el método configurando --become-method bandera. Puede obtener una lista de los métodos admitidos ejecutando el siguiente comando.

$ ansible-doc -t become -l

ansible.netcommon.enable     Switch to elevated permissions on a network device                                                             
community.general.doas       Do As user                                                                                                     
community.general.dzdo       Centrify's Direct Authorize                                                                                    
community.general.ksu        Kerberos substitute user                                                                                       
community.general.machinectl Systemd's machinectl privilege escalation                                                                      
community.general.pbrun      PowerBroker run                                                                                                
community.general.pfexec     profile based execution                                                                                        
community.general.pmrun      Privilege Manager run                                                                                          
community.general.sesu       CA Privileged Access Manager                                                                                   
community.general.sudosu     Run tasks using sudo su -                                                                                  
runas                        Run As user                                                                                                   
su                           Substitute User                                                                                               
sudo                         Substitute User DO 

puedes o no puedes sudo La contraseña para el nodo administrado depende de cómo esté configurado el usuario.En mi caso he configurado el usuario vagabundo corriendo sudo No es necesario solicitar una contraseña.

si tu sudo El usuario necesita una contraseña para trabajar, entonces debe usar -K o --ask-become-pass bandera que solicitará la entrada sudo clave.

Como puede ver en el siguiente error, cuando trato de proporcionar sudo contraseña para el usuario «karthick», me da error diciendo «Falta la contraseña de sudo».

$ ansible ubuntu1 -m service -a "name=sshd state=restarted" -i inventory -u karthick -k -b

SSH password:
managed1 | FAILED! => {
    "msg": "Missing sudo password"
}
$ ansible ubuntu1 -m service -a "name=sshd state=restarted" -i inventory -u karthick -k -b -K
Use el indicador -K para las solicitudes de contraseña de sudo
Use el indicador -K para las solicitudes de contraseña de sudo

Las contraseñas de sudo se pueden almacenar en un archivo y pasar como argumentos a --become-password-file o --become-pass-file bandera. Se puede usar Ansible Vault para cifrar este archivo, pero no se recomienda.

$ ansible ubuntu1 -m service -a "name=sshd state=restarted" -i inventory -u karthick -k -b --become-password-file pass.txt

$ ansible ubuntu1 -m service -a "name=sshd state=restarted" -i inventory -u karthick -k -b --become-pass-file pass.txt

También puedes incluir «volverse» Instrucciones en un libro de jugadas a nivel de misión o de juego.

La siguiente figura muestra cómo «volverse» Las instrucciones se utilizan para nivel de juego.

este
Directivas «convertirse» a nivel de juego

La siguiente figura muestra cómo «volverse» Las instrucciones se utilizan para nivel de tarea.

Directivas de transformación a nivel de misión
Directivas de transformación a nivel de misión

Como puede ver en la salida, ssh servicio en Alojamiento 1 nodo.

$ ansible-playbook restart_service.yml

PLAY [Restart SSHD service] ***************************************************************************

TASK [Restart SSHD in managed1.anslab.com] ************************************************************
changed: [managed1]

PLAY RECAP ********************************************************************************************
managed1 : ok=1 changed=1    unreachable=0     failed=0 skipped=0    rescued=0 ignored=0   

La directiva «become» también se puede configurar para ansible.cfg Archivos de configuración y archivos de inventario. Pero se recomienda establecer la directiva en el libro de jugadas.Puedes obtener diferentes parámetros. ansible.cfg Archivo desde el enlace a continuación.

Si desea ejecutar tareas como un usuario diferente después de conectarse al nodo administrado, debe usar --become-user bandera.De forma predeterminada, está configurado para root usuario.

En conclusión

En este artículo, vimos cómo funciona la autenticación basada en claves y contraseñas en Ansible y las diferentes banderas que admiten la autenticación. También vimos cómo funciona la escalada de privilegios en Ansible.

Para obtener una comprensión más profunda, debe tener una comprensión justa de cómo funcionan los diferentes métodos de escalada de privilegios y configurar el entorno de acuerdo con sus necesidades sin comprometer la seguridad.

Publicaciones relacionadas

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

Botón volver arriba