Hardening SSH connections to managed hosts with Red Hat Ansible Automation Platform

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!