ansible-playground

This collection includes tasks to configure SSH and add local user accounts. It verifies the SSH configuration and creates the specified users with specific attributes.

Usage

1. Install the Collection

ansible-galaxy collection install https://git.slc.ar/slococo/ansible-playground/releases/download/v1.0.0/slococo-playground-1.0.0.tar.gz

2. Create an inventory file

Create an inventory file (e.g., inventory) with the following content:

[all]
target_host ansible_host=<IP_ADDRESS_OR_HOSTNAME> ansible_user=<USERNAME> ansible_connection=ssh ansible_ssh_private_key_file=<PRIVATE_KEY_PATH>

Replace <IP_ADDRESS_OR_HOSTNAME> with the IP address or hostname of your target host, <USERNAME> with the SSH username, and <PRIVATE_KEY_PATH> with the path to the SSH private key file.

3. Run the Playbook

ansible-playbook -i inventory slococo.playground.main

Expected outcome

Upon successful execution, the playbook will:

• Create the users local_adm and local_log with the specified attributes.
• Verify the SSH configuration with the provided settings:
  • PasswordAuthentication: yes
  • PermitEmptyPasswords: no
  • PermitRootLogin: no

User configuration

local_adm:

• Username: local_adm
• Shell: /bin/bash
• User ID: 38000087
• Expiry Date: The account should not expire.
• Home Directory: /home/local_adm
• Groups: The user should only belong to its primary group.

local_log:

• Username: local_log
• Shell: /bin/sh
• User ID: 38000088
• Expiry Date: The account should expire at the end of 2024.
• Home Directory: /home/local_log
• Groups: The user should only belong to its primary group.

Moreover, since the second user has the passwordless option set to true, a key will be created in /tmp/id_ed25519_local_log on the Ansible control node. This key, once generated, allows for passwordless login as local_log. To initiate such login, simply execute the following command:

ssh local_log@<IP_ADDRESS_OR_HOSTNAME> -i /tmp/id_ed25519_local_log

Additional note

Within the slococo namespace, you will find two collections: playground and playground_nodeps. Both serve the same purpose, but the latter is intended for demonstrating how this could be achieved without using dependencies. However, it is not the primary one, as it makes the local_accounts role slightly less readable, in my opinion.