Ansible 101 – Episode 9 – First 5 min server security with Ansible


    Jeff Geerling (geerlingguy) explores Linux server security configuration using Ansible, following examples in chapter 10 of Ansible for DevOps.

    Ansible for DevOps:

    Support Jeff on GitHub:
    Support Jeff on Patreon:


    00:00:00 – Start
    00:00:35 – Intro
    00:04:26 – Questions from last episode
    00:07:42 – Linux security setup with Ansible
    00:09:50 – 9 Basic security measures
    00:12:54 – Use secure encrypted communications
    00:16:10 – History of SSH (rlogin, telnet)
    00:19:38 – Securing SSH
    00:23:50 – Ansible SSH security playbook
    00:37:29 – Managing users and sudoers
    00:43:40 – Remove unused apps
    00:46:09 – Principle of least privilege
    00:47:30 – POSIX file permissions
    00:51:00 – Automatic updates with Ansible
    00:54:59 – Configuring a firewall with Ansible
    00:59:40 – Oops – locked myself out
    01:00:37 – Security role on Galaxy
    01:01:52 – Other security concerns
    01:03:16 – Outtro


    Previous articleDeploying microservices using Ansible playbooks
    Next article#shorts Configure a #Windows Host for Ansible – #ansible #winrm


    1. Never heard of Big wheel for people in charge. But have heard similar to the following quote from the cambridge online dictionary for someone taking control, even outside driving.
      "Would you mind taking the wheel (= driving) for a couple of hours?" Only what I remember was "why don't you take the wheel" when playing games ages ago.
      From uk.

    2. "weird that it worked on port 22 with ansible there .." It's actually something the SSH client can do and is probably configured to do in your Mac, since you were already logged in in the other terminal on port 22, when you try to login a second time it will reuse that connection looking at a matching host:port:user IIRC. Once you terminate the last connection in your terminal it drops it completely so this no longer works.

    3. Thank you so much for this awesome series and all your other work! One thing I'd like to mention is that moving the ssh port to a non-privileged port above 1023 is very controversal, see e. g. Many people even see moving ssh to another privileged port as security-by-obscurity, not gaining any more security but only reducing the noise in your logs. The most important step is disabling password login, this makes brute-forcing ssh as hard as finding a single atom in the universe. Even disabling root login does not add much more security on top of that in my opinion. Especially when you create a passwordless sudo user, I don't see any benefit for this effort?
      EDIT: One word on fail2ban. While it is great to secure your webserver, there is a risk you accidently lock yourself out if you have many ssh keys and set too strict rules for the ssh port. I see no benefit using fail2ban on ssh, because guessing a secret ssh key is as impossible in 10 tries as in 10 billion tries. This might change in times of quantum computing 🙂

    4. @geerlingguy I was a bit too quick with my comment but there is additional info on how to check the validity of the sshd_config file. `sshd -f <the file to validate> -t` or `-T` for extended validation. -t is the recommended option in the sshd(8) man page.

    5. The book about SSH that was mentioned: SSH Mastery by Michael Warren Lucas is fantastic (as are his books on SNMP, ZFS, sudo and some other useful tools, skills and operating systems) and it will probably stay on your desk for a quick lookup. He also gave a talk about OpenSSH some time ago but you want the book either way now that OpenSSH is in Windows 10 and Windows Server 2019 as well. (You can install it on other recent versions of Windows using and probably at some point use Ansible over SSH with Windows instead of WinRM). And you can (mis)use SSH for almost any secure connection needs you might have, shameless plug, I gave a talk about it just last year: