Architecting Enterprise SSH Security and Management with Ansible: From Linux Hardening to Windows Server 2025 Integration

The orchestration of secure remote access is a cornerstone of modern infrastructure management. OpenSSH, the gold standard for secure shell access, provides the encrypted tunnel through which administrators manage thousands of servers. However, the default configuration of OpenSSH is often insufficient for production environments, leaving systems vulnerable to brute-force attacks, unauthorized root access, and session hijacking. Leveraging Ansible for the deployment and hardening of OpenSSH transforms a manual, error-prone process into a repeatable, version-controlled pipeline. Whether managing a fleet of Ubuntu servers through GitHub Actions or integrating Windows Server 2025 into a unified management plane, the ability to programmatically enforce security policies is critical for maintaining a robust security posture.

This comprehensive guide explores the dual nature of Ansible's application to OpenSSH: as a tool for aggressive security hardening on Linux and as a connectivity bridge for the latest Windows Server environments. By treating infrastructure as code, organizations can ensure that every server, regardless of its location or operating system, adheres to a strict security baseline without the need for manual intervention.

Comprehensive SSH Hardening Strategies via Ansible

Securing an OpenSSH server requires a multi-layered approach that minimizes the attack surface. Ansible's lineinfile and package modules allow for the precise modification of the sshd_config file, ensuring that security directives are applied consistently across the entire infrastructure.

The Technical Framework of SSH Hardening

The process of hardening begins with the installation and verification of the OpenSSH server. In Debian-based systems, this is achieved through the ansible.builtin.package module, ensuring the openssh-server is at the latest state. Before applying changes, a technical validation step is performed using the sshd -t command. This is a critical safety mechanism; if the configuration syntax is invalid, the SSH service could fail to restart, potentially locking the administrator out of the remote system.

The following table details the specific hardening measures applied to the sshd_config file and their technical justifications:

Deep Drilling into the Implementation Logic

The implementation of these measures within an Ansible role involves a structured block of tasks. By using become: true, Ansible elevates privileges to modify system-level files located in /etc/ssh/.

• Root Login Restriction: By setting PermitRootLogin no, the system forces administrators to log in as a standard user and then escalate privileges using sudo. This creates an audit trail of who accessed the system and when.
• Password Authentication Removal: Transitioning to PasswordAuthentication no ensures that only users with a valid private key corresponding to an authorized public key on the server can gain access. This is a fundamental shift from "something you know" to "something you have."
• Session Management: The ClientAliveInterval and MaxAuthTries directives are parameterized. In a production pipeline, these are often passed as variables (e.g., {{ ssh_alive_interval }} and {{ ssh_max_auth_tries }}) to allow for different security profiles across development and production environments.
• Service Persistence: The ansible.builtin.service module ensures the ssh service is started and enabled, meaning it will survive a system reboot.

Integrating Windows Server 2025 into the Ansible Ecosystem

Windows Server 2025 represents a significant shift in Microsoft's approach to remote management, as OpenSSH is now included by default. This allows Ansible to move away from the complex WinRM (Windows Remote Management) setup in favor of the more streamlined SSH protocol.

Configuring OpenSSH on Windows Server 2025

While OpenSSH is present, it is not fully configured for Ansible orchestration upon first boot. The setup requires a sequence of PowerShell commands to initialize the service and the network environment.

The following steps are required for a successful installation:

• Service Initialization: The sshd service must be set to start automatically. This is handled via PowerShell using the command set-service -name sshd -StartupType Automatic. Without this, the server will not accept SSH connections after a reboot.
• Firewall Provisioning: Windows Firewall must be configured to allow traffic on TCP port 22. The command New-NetFirewallRule -DisplayName 'Allow SSH' -Name 'Allow SSH' -Profile Any -LocalPort 22 -Protocol TCP opens the necessary port for incoming Ansible traffic.
• Shell Configuration: By default, OpenSSH on Windows may use cmd.exe. Ansible requires a more powerful shell to execute its modules correctly. The default shell must be changed to PowerShell by modifying the registry key HKLM:\SOFTWARE\OpenSSH with the value C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe.

Ansible Connection Parameters for Windows

To manage Windows Server 2025 via SSH, the Ansible inventory must be specifically configured to handle the differences between Linux and Windows shells.

The following variables must be defined in the [all:vars] section of the inventory:

• ansible_connection = ssh: This tells Ansible to use the SSH transport layer instead of the default Windows WinRM.
• ansible_shell_type = powershell: This is a critical setting. It informs Ansible that the remote end is executing PowerShell, ensuring that the modules are wrapped in the correct syntax.
• ansible_ssh_common_args = '-o StrictHostKeyChecking=no': During the initial deployment, the remote host's key is unknown to the Ansible controller. Disabling strict host key checking prevents the automation from halting due to an unverified host key.

Automating SSH Hardening with GitHub Actions

The integration of Ansible into a CI/CD pipeline via GitHub Actions allows for "Push-to-Hardening" workflows. This ensures that any new server added to the infrastructure is automatically secured according to the organization's baseline.

The Workflow Architecture

The automation relies on two primary GitHub workflows: ssh.yml for hardening and ufw.yml for firewall management. These workflows use workflow_dispatch to allow administrators to trigger the hardening process with specific inputs.

The input parameters for the hardening workflow include:

• REMOTE_USER: The username used to connect to the target.
• TARGET_HOST: The IP address or hostname of the remote server.
• SSH_PORT: The current port of the SSH server.
• SSH_NEW_PORT: The desired custom port to move the service to (defaulting to 2222).
• SSH_ALIVE_INTERVAL: The timeout value (defaulting to 300).
• SSH_MAX_AUTH_TRIES: The maximum login attempts (defaulting to 3).

Managing Secrets and Privileged Access

A major challenge in automation is the handling of sudo passwords without exposing them in logs. This is solved through the use of an encryption script and Ansible Vault.

The script create-sudo-password-ansible-secret.sh performs the following technical operations:

• It generates a random 12-character vault password using openssl rand -base64 12.
• It creates a temporary file containing the sudo password in the format ansible_sudo_pass: "password".
• It uses ansible-vault encrypt to encrypt the sudo password file, using the generated vault password for encryption.
• This allows the playbook to run become: true tasks using the encrypted secret, which is passed at runtime via the --vault-password-file flag.

The Execution Pipeline

The GitHub Action job runs on an ubuntu-latest runner and follows a strict execution sequence:

• Checkout: Uses actions/checkout@v2 to pull the repository code.
• Key Deployment: The private SSH key is injected from GitHub Secrets into a file at ansible/ssh-key and its permissions are restricted using chmod 400 to satisfy OpenSSH security requirements.
• Environment Setup: Ansible is installed via pip install ansible.
• Dynamic Configuration: The workflow dynamically generates the inventory.ini and ansible.cfg files. The ansible.cfg file is configured with host_key_checking=False and the path to the private key, ensuring a seamless connection to the target host.
• Playbook Execution: The final step executes the playbook using the command ANSIBLE_CONFIG=ansible/ansible.cfg ansible-playbook ssh.yml --vault-password-file=ansible/vault.txt.

Infrastructure as Code Directory Structure

For a successful deployment of this architecture, the project must follow a modular directory structure. This ensures that tasks are separated by function and can be reused across different environments.

The following structure is utilized:

• .github/workflows/: Contains ssh.yml and ufw.yml for CI/CD orchestration.
• ssh/tasks/main.yml: Contains the logic for OpenSSH hardening.
• ufw/tasks/main.yml: Contains the logic for Uncomplicated Firewall configuration.
• ssh.yml and ufw.yml: The primary playbooks that call the respective roles.
• create-sudo-password-ansible-secret.sh: The utility script for secure credential handling.

Conclusion: An Analysis of the Security Impact

The shift from manual SSH configuration to an Ansible-driven pipeline represents a transition from "hope-based security" to "verified security." By utilizing the methods described, the risk of human error—such as forgetting to disable root login or leaving the default port 22 open—is entirely eliminated.

The integration of Windows Server 2025 into this ecosystem is particularly significant. By leveraging the native OpenSSH installation and configuring the PowerShell shell as the default, administrators can apply a unified management logic across heterogeneous environments. The use of GitHub Actions further enhances this by providing an immutable audit trail of every security change applied to the infrastructure.

The combination of PermitRootLogin no, PasswordAuthentication no, and the use of Ansible Vault for secret management creates a hardened environment where the only way to gain access is through a pre-authorized SSH key and a documented sudo escalation. This architecture not only protects the server from external threats but also enforces internal governance and compliance standards.

Sources

1. Strengthen OpenSSH Security through Ansible and GitHub Actions
2. How to Configure SSH on Windows Server 2025 for use with Ansible