Set Up Ansible with Kerberos on a PHX Development Desktop

In the air-gapped PHX domain, Kerberos enables secure authentication in the Ansible development environment on an Ubuntu 22/24-based desktop, improving both convenience and security.

Tags:

Projects: c2platform/phx/ansible

Overview

The Ansible development environment in the air-gapped PHX domain differs from the open-source PHX development environment (PXD). The PXD is fully open-source and part of the C2 Platform initiative. It uses Vagrant and Ansible without Kerberos, making it easier for quick setup and testing. In contrast, the PHX environment relies on Kerberos for authentication and vRA for infrastructure provisioning, without Vagrant. This setup is less suited for rapid Ansible development, as it lacks features like easy VM creation, snapshots, and automated environment management. For this reason, it’s often referred to as a pseudo development environment, involving more manual steps.

This guide explains how to simulate the PHX Ansible development environment setup. You’ll set up an Ubuntu 22.04 desktop VM named pxd-ubuntu-devtop using Vagrant and Ansible. Once provisioned, connect to it via SSH or Remmina (for RDP access). From there, perform Ansible tasks in this sandbox using Kerberos authentication, mirroring the PHX domain setup.

This simulation facilitates understanding of how the Ansible development environment is set up and works in the PHX domain. It also forms a basis for creating and validating automation for managing the development environment. It enables developers to test and develop Ansible playbooks in a controlled, Kerberos-enabled environment without needing access to the actual air-gapped PHX domain. It emphasizes security best practices, such as using forwardable Kerberos tickets for seamless multi-hop authentication, while maintaining isolation for development and testing.

Note:

Kerberos authentication is used for SSH for both Linux and Windows connections in this how-to. This is configured by overriding the default basic authentication settings in the Ansible inventory project ( c2platform/phx/ansible ). Kerberos authentication is enabled for domain user tony, by setting the environment variable ANSIBLE_INVENTORY to Vagrantfile.yml,hosts.ini,hosts-kerberos-override.ini.

You can easily switch between Ansible connections settings as follows:

To use SSH with Kerberos for both Linux and Windows hosts:
```
export ANSIBLE_INVENTORY="Vagrantfile.yml,hosts.ini,hosts-kerberos-override.ini"
```
This will be the default for user tony, because he will add this to .bash_aliases file.
To use SSH for Linux hosts and WinRM for Windows hosts with basic authentication (using user vagrant):
```
export ANSIBLE_INVENTORY="Vagrantfile.yml,hosts.ini"
```

To use SSH for Linux hosts and WinRM for Windows hosts with Kerberos authentication:

export ANSIBLE_INVENTORY="Vagrantfile.yml,hosts.ini,hosts-kerberos-override.ini,hosts-kerberos-winrm-override.ini"

Prerequisites

Before starting, ensure you have completed the following:

Ansible Development Desktop in PHX Domain: Set up and manage an Ansible development desktop simulating the setup in the air-gapped PHX domain.
Ensure necessary nodes are running, if not start them first:
```
vagrant up pxd-rproxy1 pxd-ad pxd-win1
```

Setup Ansible Development Environment

Step 1: Connect to Ansible Development Desktop

Using Remmina, log in as tony with your password (e.g., Supersecret!for testing).

Verify the Kerberos configuration tool version:

krb5-config --version

Show me

tony@pxd-ubuntu-devtop:~$ krb5-config --version
Kerberos 5 release 1.19.2

Check your current Kerberos tickets:

klist

Show me

tony@pxd-ubuntu-devtop:~$ klist
Ticket cache: FILE:/tmp/krb5cc_747001104_4yJsHO
Default principal: tony@C2.ORG

Valid starting       Expires              Service principal
07/24/2025 11:06:24  07/24/2025 21:06:24  krbtgt/C2.ORG@C2.ORG
	renew until 07/25/2025 11:06:24

Step 2: Customize Your Terminal

Create a file for Bash aliases to simplify your workflow and improve productivity:

export BASH_ALIASES_URL="https://gitlab.com/c2platform/phx/ansible/-/raw/master/plays/dev/files/.bash_aliases"
curl -sL $BASH_ALIASES_URL  > ~/.bash_aliases

These aliases streamline common tasks, such as activating the virtual environment, navigating to project directories, and managing Ansible installations. For more information:

Example Bash Aliases File

Step 3: Set Up Python Virtual Environment

Create a Python 3 virtual environment for Ansible to ensure isolation, stability, and reproducibility:

sudo apt update
sudo apt install virtualenv -y
mkdir ~/.virtualenv
DEB_PYTHON_INSTALL_LAYOUT='deb' virtualenv ~/.virtualenv/pxd -p python3

This setup prevents conflicts with system-wide Python packages and aligns with best practices for development environments.

Step 4: Clone Projects

Load your Bash configuration and install required tools:

source ~/.bashrc
sudo apt install git curl -y
curl -s -L https://gitlab.com/c2platform/phx/ansible/-/raw/master/clone.sh | bash

As a security best practice, always review the contents of scripts like clone.sh before executing them via curl and bash. Download and inspect the script first to ensure it aligns with your security standards.

Step 5: Install Ansible and Ansible Roles/Collections

Activate the environment and install dependencies:

source ~/.bashrc
phx
pip install -r requirements.txt

Use the predefined aliases to install Ansible collections and Ansible roles:

phx-collections
phx-roles

This step ensures all required Ansible components are installed in the virtual environment, promoting scalability and consistency.

Step 6: Set Ansible Vault Password

In order for user tony to use Ansible, he has to set the Ansible Vault password of the inventory, which is secret. He utilizes the phx-vault-password function:

phx
phx-vault-password

The output below shows the result of running the command:

(pxd) tony@pxd-ubuntu-devtop:~/git/gitlab/c2/ansible-phx$ phx
phx-vault-password
Password doesn't exist or is empty, lets add/set it!
Password:
Vault password has been set.
(pxd) tony@pxd-ubuntu-devtop:~/git/gitlab/c2/ansible-phx$

If you run the command for the first time, you are asked to set a password for the GNOME Keyring¹. The Ansible Vault password will be stored there for convenience (you don’t have to provide the password each time you use Ansible) and also security. It is a safe place. The screenshot below shows the GNOME Keyring prompt asking for password and password confirmation.

This securely handles sensitive data, following best practices for secret management in Ansible. For more details, see:

Securely Accessing Ansible Vault in Development: Guideline for securely accessing Ansible Vault during development without storing passwords in plain files, using GNOME Keyring or environment variables.

Step 7: Ansible Ping

Verify the setup by pinging a Windows host:

ansible -m win_ping pxd-ad

Verify the setup by pinging a Linux host:

ansible -m ping pxd-ubuntu-devtop

Show me

(pxd) tony@pxd-ubuntu-devtop:~/git/gitlab/c2/ansible-phx$ ansible -m win_ping pxd-ad
[WARNING]: Collection ansible.windows does not support Ansible version 2.15.3
pxd-ad | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
(pxd) tony@pxd-ubuntu-devtop:~/git/gitlab/c2/ansible-phx$ ansible -m ping pxd-ubuntu-devtop
pxd-ubuntu-devtop | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

Target Windows and Linux Hosts Using Kerberos and SSH

This section tests Ansible plays to confirm Kerberos authentication via SSH for both Linux and Windows hosts. Run the following plays, which should succeed without errors:

ansible-playbook plays/mgmt/ad.yml

ansible-playbook plays/core/win.yml --limit pxd-win1

ansible-playbook plays/mw/reverse_proxy.yml

To confirm Kerberos was used, destroy your ticket:

kdestroy

Verify no active tickets remain:

klist

Show me

(pxd) tony@pxd-ubuntu-devtop:~/git/gitlab/c2/ansible-phx$ kdestroy
(pxd) tony@pxd-ubuntu-devtop:~/git/gitlab/c2/ansible-phx$ klist
klist: No credentials cache found (filename: /tmp/krb5cc_149801104_45UGBy)

Re-running the last play will fail without a ticket:

ansible-playbook plays/mw/reverse_proxy.yml

(pxd) tony@pxd-ubuntu-devtop:~/git/gitlab/c2/ansible-phx$ ansible-playbook plays/mw/reverse_proxy.yml
ini_path: /home/tony@c2.org/git/gitlab/c2/ansible-phx/hosts.ini
[DEPRECATION WARNING]: community.general.yaml has been deprecated. The plugin
has been superseded by the the option `result_format=yaml` in callback plugin
ansible.builtin.default from ansible-core 2.13 onwards. This feature will be
removed from community.general in version 13.0.0. Deprecation warnings can be
disabled by setting deprecation_warnings=False in ansible.cfg.

PLAY [Reverse proxy] ***********************************************************

TASK [Gathering Facts] *********************************************************
fatal: [pxd-rproxy1]: UNREACHABLE! => changed=false
  msg: 'Failed to connect to the host via ssh: tony@pxd-rproxy1.c2.org: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).'
  unreachable: true

PLAY RECAP *********************************************************************
pxd-rproxy1                : ok=0    changed=0    unreachable=1    failed=0    skipped=0    rescued=0    ignored=0

Before continuing, recreate a forwardable ticket:

kinit -f

Target Hosts Using SSH for Linux and WinRM with Basic Authentication for Windows

This setup mirrors how Vagrant connects to boxes using basic authentication (with user vagrant). Set the inventory:

export ANSIBLE_INVENTORY="Vagrantfile.yml,hosts.ini"

Re-run the plays from the previous section. They should provision without failures.

Target Windows Hosts Using Kerberos and WinRM

This configuration uses SSH for Linux and Kerberos WinRM for Windows. Set the inventory:

export ANSIBLE_INVENTORY="Vagrantfile.yml,hosts.ini,hosts-kerberos-override.ini,hosts-kerberos-winrm-override.ini"

Re-run the plays from the Kerberos SSH section. They should succeed, confirming Kerberos WinRM for Windows.

Review

User tony is working with a customized Ansible configuration through his .bash_aliases using the ANSIBLE_INVENTORY variable and a separate Ansible configuration file hosts-kerberos-override.ini, which he adds to inventory by including it in ANSIBLE_INVENTORY, overriding the normal/default settings.

plays/dev/files/.bash_aliases

11export ANSIBLE_INVENTORY="Vagrantfile.yml,hosts.ini,hosts-kerberos-override.ini"

hosts-kerberos-override.ini

18[linux:vars]
19ansible_connection=ssh
20ansible_kerberos=yes
21ansible_user=
22ansible_password=
23
24[win:vars]
25ansible_connection=ssh
26ansible_kerberos=yes
27ansible_shell_type=powershell
28# ansible_shell_executable=cmd.exe
29ansible_user=
30ansible_password=

To activate the default setup that Vagrant uses, to use SSH for Linux hosts and WinRM for Windows hosts with basic authentication:

export ANSIBLE_INVENTORY="Vagrantfile.yml,hosts.ini"

hosts.ini

10[linux:vars]
11ansible_user=vagrant
12ansible_password=vagrant
13
14[win:vars]
15#ansible_connection=ssh
16#ansible_shell_type=cmd
17ansible_user=vagrant
18ansible_password=vagrant
19ansible_connection=winrm
20#ansible_port=5985
21ansible_winrm_transport=basic
22ansible_winrm_server_cert_validation=ignore

To use SSH for Linux hosts and WinRM for Windows hosts with Kerberos authentication:

export ANSIBLE_INVENTORY="Vagrantfile.yml,hosts.ini,hosts-kerberos-override.ini,hosts-kerberos-winrm-override.ini"

hosts-kerberos-winrm-override.ini

4[win:vars]
5ansible_connection=winrm
6ansible_kerberos=yes
7ansible_winrm_transport=kerberos

Additional Information

GNOME Keyring is a secure storage daemon for managing passwords, keys, and certificates in GNOME-based Linux environments. It provides encrypted storage and automatic unlocking during user sessions, enhancing security for sensitive data like Ansible Vault passwords. ↩︎

Feedback

Was this page helpful?

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.

Last modified February 2, 2026: howto phx desktop setup-environment PHX-248 C2-1236 (5472cbe)