DEV Community

Gabriel
Gabriel

Posted on

Automating SSH Access to 100+ AWS EC2 Instances with Ansible - No PEM Files, No Manual Login . .Nothing!!!

Tired of juggling PEM files and manually logging into AWS instances one by one?

I was until I automated SSH access across 100+ EC2s with Ansible, achieving zero manual login and creating reusable playbooks that changed my workflow. This isn't just about convenience; it's about building scalable, secure, and efficient infrastructure.

As an automations engineer, I've seen firsthand how quickly manual tasks can become bottlenecks, especially when dealing with cloud infrastructure at scale. This problem specifically around SSH access was a recurring frustration.

The Problem
Spinning up EC2 instances on AWS is incredibly easy - a few clicks or an API call, and you're good to go right?. The challenge arises when it's time to consistently configure passwordless SSH access on all of them.

You usually face two less-than-ideal options:

  1. Manually log into each instance to set up the authorized_keys file for evey user.
  2. Depend forever on perishable PEM files, which can be lost, misused, or require constant manual management.

I quickly realized that neither of these approaches would scale with the growing number of instances and the need for consistent, repeatable deployments. So, I challenged myself:

How can I automate SSH key access just once and never touch these boxes manually again?

The Goal
My objective was clear: establish passwordless SSH access across all EC2 instances using a fully automated approach, leveraging the power of:

  • Ansible: For orchestration and configuration management.

  • A single public key: As the single source for access.

The Ansible Setup
Here’s the core Ansible configuration that makes this possible:

[defaults]
inventory = /home/ec2-user/inventory.ini
remote_port = 22
remote_user = ec2-user
private_key_file = /home/ec2-user/control-node.pem

[privilege escalation]
become = true
become_user = root
become = sudo
Enter fullscreen mode Exit fullscreen mode

Part 2: The Playbook

---
- name: Setting up SSH access
  hosts: all
  become: true
  tasks:
    - name: Set authorized key from control node's public key
      ansible.posix.authorized_key:
        user: ec2-user
        state: present
        key: "{{ lookup('file', '/home/ec2-user/.ssh/id_rsa.pub') }}"
Enter fullscreen mode Exit fullscreen mode

The Flow
This streamlined process, visualized in the above, involves just a few key steps:

  1. Generate SSH Key: On the Ansible control node, I generated a new SSH key pair (id_rsa and id_rsa.pub) using ssh-keygen.

  2. Extract Public Key: The public key (id_rsa.pub) is extracted and made ready for distribution.

  3. Initial Connection: I used the control node's PEM key (specified in private_key_file in ansible.cfg) just once to establish a secure connection to the target EC2 instances.

  4. Execute Ansible Playbook: Ansible then took over, executing the ssh.yml playbook on the target instances.

  5. Public Key Push: This playbook pushed the content of id_rsa.pub from the control node.

  6. Key Storage: The public key is stored in the ~/.ssh/authorized_keys file of the ec2-user on every managed instance.

Subsequent SSH Login and result? Now I can log in to any node directly with my private SSH key (id_rsa) from the control node the initial PEM file is no longer needed for subsequent access! This means enhanced security and vastly improved operational efficiency.

Why This Matters (especially for RHCE & Cloud Engineers)
This approach offers significant advantages:

Infrastructure-as-Code: It replaces tedious, error-prone manual labor with defined, repeatable code, making your infrastructure setup consistent and auditable.
Real-World Automation: It perfectly mimics the kind of robust automation required in cloud-scale environments, setting a foundation for CI/CD pipelines.
Enhanced Security: By centralizing key management and eliminating the need to distribute or constantly use sensitive PEM files, it significantly reduces the attack surface and potential for key compromise. Your PEM file is used once for initial setup, then secured offline.
RHCE Relevance: For RHCE students, this directly checks off critical objectives related to Ansible and secure SSH key management.

SOme weird tips:

Secure Your PEM File: Always secure your initial PEM file and remove it from version control. Consider using a secrets management tool for it.
Image
Provisioning: Integrate this method into your image provisioning pipelines (e.g., Packer) to bake in SSH access from the start.
Ansible Role: Convert this playbook into a reusable Ansible role for easy integration into future projects and playbooks.
Temporary Password Access: If you don't want to pass a PEM file even once, you can temporarily use --ask-pass with Ansible for password-based authentication (if enabled on the remote host) or ssh-agent for managing keys.

How are you managing SSH access at scale in your cloud or hybrid environments? But wait, WHat happens if i provisioned all ec2 instances using different PEM keys. OOOps....

Follow for more real-world DevOps workflows and feel free to remix this playbook to fit your pipeline.. Chao!!

Top comments (0)