Ansible Automation
EX294 RHCE
Andrew Mallett
LINUX	AUTHOR	AND	TRAINER
@theurbanpenguin
Course Objectives
                    Red Hat Certification
                    What is Ansible
                    Installing Ansible on on Kali
                    Listing SSH Servers to Create Inventory
                    Distribute SSH Key
                    Audit SSH with NMAP
                    Tighten SSH Security with Ansible
@theurbanpenguin
Red Hat Certification
Red Hat have the most recognized Linux
Certifications in the industry. This course follows
RH294 SysAdmin 3. Some previous Linux
Administration experience is required for this
course.
RHCSA
• RH124	System	Administration	1	
• RH134	System	Administration	2
• EX200	RHCSA	Exam
RHCE
• RH294	System	Administration	3
• EX294	RHCE	Exam
@theurbanpenguin
1. Installing Ansible
Learn about Ansible and how to install it
What is Ansible
Configuration management system that is
agentless, the software only needs to be installed
on the controller. Using Playbooks we can
configure managed nodes to the desired state.
Ansible Controller:
•   macOS or	Linux
•   Managed	nodes	can	be	Linux,	Windows	or	Networking	Devices
•   Linux	nodes	are	managed	via	SSH
•   Ideally	passwordless access	via	SSH	and	sudo is	maintained
•   Ansible uses	Python	modules	to	manage	Linux
No agent software is needed on the managed
nodes
@theurbanpenguin
# CentOS
$ sudo yum install epel-release
$ sudo yum install ansible
$ ansible --version
# Kali
$ sudo apt install ansible sshpass
$ ansible --version
Installing Ansible
In the exam only Red Hat 8 is used CentOS replicates
RHEL 8 and Ansible is available though the EPEL
repository
@theurbanpenguin
$ sudo nmap -p 22 -n 45.33.32.156 192.168.0.0/24 172.16.120.130 --open -oG -
| awk '/22\/open/{ print $2 }'
NMAP
The port scanner nmap is installed by default on Kali.
With a little knowledge of both nmap and awk we can
list servers that listen on port 22, listing SSH servers
@theurbanpenguin
Installing Ansible
We can install Ansible on Kali Linux and
create an inventory of SSH Servers
2. Configuring Ansible
Learn about Ansible Configuration Files and
Variable
Ansible Configuration
The default configuration for Ansible is the
/etc/ansible/ansible.cfg file. This is often not used
as we usually opt to have configuration files per
project. Also being in the /etc directory only root
can write to this file and most times configuration
can be run on the controller node by standard
accounts. The ansible.cfg file is written in an INI
style
@theurbanpenguin
Ansible Configuration Hierarchy
                   Environment Variable ANSIBLE_CONFIG
                   ansible.cfg in working directory
                   $HOME/.ansible.cfg
                   /etc/ansible/ansible.cfg
@theurbanpenguin
Readonly Variables
                   If we need to enforce the ansible.cfg location
                   we can use the ANSIBLE_CONFIG variable and
                   set it in the /etc/profile. User's can still
                   overwrite this. If the variable is configured
                   as readonly it cannot be overridden:
                   declare -xr ANSIBLE_CONFIG=/etc/ansible.cfg
@theurbanpenguin
[defaults]
inventory = inventory ; set the file inventory in the working directory
remote_user = tux
# Full comment
[privilege_escalation]
become = true ; or set in play when needed
become_method = sudo
Sample Configuration
The ansible.cfg is a INI file format. Comments can be
the # or ;
@theurbanpenguin
Working with Ansible
Configuration
Let’s take a look at the configuration and
how we can control the file that is used.
4. Ad-hoc Commands &
Preparation
Preparing to run commands and running
Ansible ad-hoc comands across systems
Ad-hoc Commands
Mostly people think of Playbook to execute
Ansible code. We can though run code direct from
the CLI as ad-hoc commands. We can set options
to overwrite the current configuration or
inventory
Ad-hoc commands can include:
•   ansible program
•   -m	to	reference	the	ansible module
•   -a	to	reference	optional	arguments	to	to	module
•   -i to	reference	a	different	inventory
•   -k	to	prompt	for	ssh password
.
@theurbanpenguin
Configuring Ansible Connections
                   SSH Pubic Key Managed Hosts
                   Remote User Accessible SSH Key Auth
                   Remote User SUDO Access
@theurbanpenguin
$ for h in 192.168.56.{2..4}; do ssh-keyscan $h >> ~/.ssh/known_hosts ; done
$ ssh-keygen
Basic Configuration
We should have the public key of the managed
servers stored locally. We also generate a key pair for
the tux user account.
@theurbanpenguin
$ ansible all -k -K -m ping
Ping Hosts
The simplest of ad-hoc commands is the ping module. This
looks for the python interpreter on the managed host. We
can use -k to prompt for SSH password and -K to prompt
for sudo password
@theurbanpenguin
$ ansible all -k -m authorized_key \
  -a "user='tux' state='present' \
  key='{{ lookup('file','/home/tux/.ssh/id_rsa.pub')}}'"
Distribute SSH Key
Modules can also make use of arguments and we can
see that in distributing the tux public key to the tux
user on each node.
@theurbanpenguin
$ echo "tux ALL=(root) NOPASSWD: ALL" > tux
$ sudo visudo -cf tux
$ ansible all -b -K -m copy -a "src=tux dest=/etc/sudoers.d/tux"
Copy Sudoers Files
To allow for passwordless sudo access we can create a
file locally and distribute it to the managed nodes.
@theurbanpenguin
$ ansible-doc -l
$ ansible-doc -l | grep ping
$ ansible-doc user
Help on Modules
List module with ansible-doc -l. Gain help on a
module with ansible-doc <module-name>
@theurbanpenguin
$ ansible 192.168.56.2 -b -m user -a "name=fred”
$ ansible 192.168.56.2 -b -m user -a "name=fred state=absent”
$ ansible 192.168.56.2 -b -m user -a "name=fred state=absent remove=true"
Create User
With the user module we need to at least specify the user
name as an argument. Here we run across just the single
host listed in the inventory. We ensure we run as root with
the -b option. Delete the user with state=absent.
@theurbanpenguin
Using Ad-hoc
Commands in Ansible
In this demonstration we get used to the
the power of Ansible and test our
configuration using ad-hoc commands
Ad-hoc Commands Summary
                   Ad-hoc commands run with the ansible command
                   -K prompt for sudo password
                   -k prompts for SSH password
                   -b elevates privileges
                   -m specifies the module
                   -a set the module arguments
                   ansible -b -m user -a "name='bob' state='present'"
                   ansible-doc user
@theurbanpenguin
5. Security Audit and
Configuration
We can audit SSH with nmap and push out
configuration
$ sudo nmap -p 22 --script ssh-auth-methods \
  --script-args="ssh.user=root" -iL ssh.txt
Auditing SSH
Using the list of SSH Servers we can further look to
see their authentication methods. Password based
login should not be enabled.
@theurbanpenguin
Service Configuration Changes Requires Restart
Changing a service configuration      Handlers are similar to tasks and
will usually required a service to    exist in a play. Handlers run when
be restarted; the restart will only   triggered by tasks that have
be required if the changes took       implemented a change
place
@theurbanpenguin
Service / Systemd Module
On modern Linux systems we can use the systemd
module over the service module. The service
module provides more compatibility across mixed
systems
- name: ensure ssh started and enabled
  systemd:
    name: sshd
    enabled: true
    state: started
@theurbanpenguin
---
- name: Configure SSHD
  hosts: all
  become: true
  gather_facts: False
  tasks:
    - name: Password
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^PasswordAuthentication '
        insertafter: '#PasswordAuthentication '
        line: 'PasswordAuthentication no'
      notify: restart_sshd
Securing the SSH Server
As a minimum we would want to ensure that root
logins are not allowed to the Linux servers. The notify
key is part of the task and inline with the task name.
@theurbanpenguin
---
- name: Configure SSHD
  hosts: all
  become: true
  gather_facts: False
  handlers:
    - name: restart_sshd
      systemd:
        name: sshd.service
        state: restarted
Handlers
Ansible handlers exist in plays, as to task lists. Unlike tasks
they do not run automatically and are triggered by tasks.
The list of handlers may come before or after the task list
@theurbanpenguin
---
- name: Configure SSHD
    hosts: all
    become: true
    gather_facts: False
  handlers:
    - name: restart_sshd
      systemd:
        name: sshd.service
        state: restarted
  tasks:
    - name: Password
      lineinfile:
         path: /etc/ssh/sshd_config
         regexp: '^PasswordAuthentication '
         insertafter: '# PasswordAuthentication '
         line: ' PasswordAuthentication no'
      notify: restart_sshd
    - name: Enable SSHD
      systemd:
         name: sshd.service
         enabled: true
@theurbanpenguin
Configuring the SSHD
In this demonstration we learn to use
handlers to restart services if their
configuration has changed
http://bit.ly/centos8-rhce
       Andrew Mallett
       LINUX	AUTHOR	AND	TRAINER
          @theurbanpenguin
@theurbanpenguin   theurbanpenguin.com
@theurbanpenguin
        These items allow you to individually copy and paste them to anywhere else in your presentation.
These items are PowerPoint drawing objects and as such can be reduced or enlarged without any loss of resolution.