Red Hat Ansible Automation Platform is a platform for implementing enterprise-wide automation, which makes it an ideal tool for your security audits. Security has many layers, but this article focuses on mitigating SSH attacks on managed hosts. While you can't eliminate all security risks, you can harden managed hosts to minimize some of them (especially brute force attacks), and mitigate others (by allowing SSH connections only from authorized hosts, enforcing sudo, and so on). This article uses Ansible Automation Platform, but most of the hardening configuration is applied to the managed hosts (editing sshd_config, sssd.conf, access.conf) so you can apply these concepts with other centralized configuration tools like Red Hat Satellite.
This article demonstrates how you can harden your managed host configuration using this schema:
- Multiple service accounts for SSH login to the hosts, created in AD/LDAP:
- Public key stored in AD/LDAP for SSH login with public key authentication
- Password stored in AD/LDAP for sudo only (not for SSH login)
- On any managed host:
- A service account can login only from Ansible Automation Platform execution nodes (any attempt to log in from anywhere else is rejected)
- Privilege escalation with sudo for any service account requires a password

Setup
Start from a standard non-hardened deployment, which typically includes:
- One Ansible Automation Platform service account
- Used for SSH login to the hosts
- Created in AD/LDAP with a random password
- On any host:
- Service account can log in with the password
- Service account can sudo without using password
Hardening the configuration
Many companies create only one service account for each service. In this Ansible Automation Platform scenario, only one service account is created for use with Ansible Automation Platform to connect to all the managed hosts. However, if for any reason this service account is compromised, the attacker could access any managed host.
This is the first change you must make. Security happens in layers, and one important foundation is to create different service accounts. There's not a universal approach when implementing this. Review your architecture and decide what makes the most sense for your infrastructure. Here are some common strategies for creating different service accounts:
- Location or datacenter: Create one service account for each data center
- Organization or Domain: Create one service account for each organization or domain
- OS: Create one service account for each host type (Red Hat Enterprise Linux 7, 8, 9, and so on)
- Usage: Create one service account for each host usage of main application (Database, Apache, Kafka)
- Security: Create one service account for each security zone (DMZ, Internal Zone 1, and so on)
Create a common group for all service accounts. This makes it easier to allow one service account while denying access to all others.
SSH public key authentication using AD/LDAP
Base the SSH authentication for service accounts on public keys. Although public keys have some drawbacks over passwords, using keys eliminates brute force attack effectiveness for SSH login.
First, add public SSH keys of each service account to the altSecurityIdentities
attribute in AD/LDAP.
On each managed host, append ssh to the services list in /etc/sssd/sssd.conf
:
services = nss, pam, ssh
Add ldap_user_extra_attrs
and ldap_user_ssh_public_key
parameters to the [domain]
section of /etc/sssd/sssd.conf
:
[domain/example.com] ldap_user_extra_attrs = altSecurityIdentities ldap_user_ssh_public_key = altSecurityIdentities
The AuthorizedKeysCommandUser
option specifies the user account used to run AuthorizedKeysCommand
. It's recommended that you use a dedicated user for this, so add these SSH parameters to /etc/ssh/sshd_config
:
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys AuthorizedKeysCommandUser nobody
For more information, read Store User SSH Keys in Active Directory for SSH Authentication on Red Hat Customer Portal.
Deny password authentication
Add these SSH parameters to /etc/ssh/sshd_config
on all managed hosts to deny using SSH password authentication (replace <Service Account> with the actual name of the service account):
Match User <Service Account> PasswordAuthentication no Match all
Require password for sudo
For sudo, request the password for the service account. To do this, create a new file named for the service account group in /etc/sudoers.d
and add this line:
%<Service Account Group> ALL=(ALL:ALL) ALL
For example, if the group name is aapsas
:
$ cat /etc/sudoers.d/aapsas %appsas ALL=(ALL:ALL) ALL
Although security best practices recommend adding only some specific allowed command to run sudo, this is not possible with Ansible Automation Platform. For managed hosts, Ansible Automation Platform communicates to the target machines (most commonly using SSH), and copies and executes a Python script.
Allow connections from authorized Ansible Automation Platform execution nodes
The final hardening configuration is to allow SSH connections for a service account coming only from Ansible Automation Platform execution nodes or LOCAL
(for sudo). To implement this, you add a line in /etc/security/access.conf. The first line allows connections from Ansible Automation Platform and LOCAL, while the other forbids any other service account.
+: <Service Account> : <AAP Execution Nodes IPS> LOCAL -: <Service Account Group> : ALL
Automating all the configuration
This article has provided the steps you need to harden your managed hosts for SSH login, but this is Ansible Automation Platform so you don't have to do it all manually. All the configuration steps I've covered are easily automated using the template module. Make templates for the configuration files /etc/security/access.conf
, /etc/sssd/sssd.conf
and /etc/ssh/sshd_config
.
You're changing the connection security parameters of your target host, so be careful! An errant configuration could cause the sshd service to fail, or grant access to users who don't need access, and so on. Double-check your work before propagating the changes.
Of course, good security isn't a one-time configuration. Hardening your SSH configuration for your managed hosts is an important step in an ongoing process, and it's made easier thanks to Ansible Automation Platform!
About the author
Alberto Gonzalez de Dios is a Senior Cloud consultant: Automation and OpenShift specialist. He joined Red Hat in 2018, and he is certified in Azure, AWS and Red Hat (Red Hat Certified Architect Level II).
Browse by channel
Automation
The latest on IT automation for tech, teams, and environments
Artificial intelligence
Updates on the platforms that free customers to run AI workloads anywhere
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
The latest on how we reduce risks across environments and technologies
Edge computing
Updates on the platforms that simplify operations at the edge
Infrastructure
The latest on the world’s leading enterprise Linux platform
Applications
Inside our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Customer support
- Developer resources
- Find a partner
- Red Hat Ecosystem Catalog
- Red Hat value calculator
- Documentation
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit