How to Fix Ansible 403 Forbidden on DigitalOcean Droplet

As a Senior DevOps Engineer, encountering “Ansible 403 Forbidden” can be a bit perplexing, especially when dealing with a seemingly straightforward setup like DigitalOcean Droplets. This error doesn’t signify an HTTP 403 status; rather, it’s Ansible’s way of telling you that a command it tried to execute on the remote host (your Droplet) was forbidden due to insufficient permissions. Let’s break down how to diagnose and resolve this common issue.

1. The Root Cause: Why This Happens on DigitalOcean Droplet

The “Ansible 403 Forbidden” error, in the context of connecting to a DigitalOcean Droplet, almost invariably points to a privilege escalation failure or incorrect user permissions on the target Droplet. Ansible relies heavily on SSH for communication and then typically uses sudo for tasks requiring elevated privileges.

The most common scenarios leading to this error are:

  1. Insufficient sudo Permissions: The user Ansible connects as either doesn’t have sudo privileges at all, or requires a password for sudo and Ansible isn’t configured to provide it (ansible_become_pass). DigitalOcean Droplets often default to a root user and encourage the creation of a non-root user with sudo access.
  2. PermitRootLogin Restrictions: The SSH daemon (sshd) on your Droplet might be configured to deny direct root login (PermitRootLogin no or prohibit-password in /etc/ssh/sshd_config). If Ansible is attempting to connect as root without proper SSH key authentication or a non-root user is expected, this will lead to a connection or permission failure.
  3. SSH Key Permissions on Droplet: While less common for a “forbidden” error (more for connection refused), incorrect permissions on the ~/.ssh directory or ~/.ssh/authorized_keys file for the connecting user on the Droplet can prevent authentication or execution.
  4. SELinux/AppArmor Interference: On some Linux distributions or custom configurations, security modules like SELinux or AppArmor might be blocking certain operations, even if the user theoretically has permissions. This is less frequent on a standard DigitalOcean Ubuntu/CentOS image but worth noting.

In essence, Ansible is trying to do something, and the remote Droplet is saying “No, you don’t have permission to do that.”

2. Quick Fix (CLI)

Assuming you can still access your DigitalOcean Droplet via SSH (either as root or an existing sudo user), here are immediate steps to address the most common causes.

Login to your DigitalOcean Droplet (e.g., via ssh root@your_droplet_ip) and execute the following:

  1. Create a dedicated Ansible user (if not already existing) and grant sudo privileges:

    # Create a new user (e.g., 'ansibleuser')
sudo adduser ansibleuser

# Add the user to the 'sudo' group (for Ubuntu/Debian)
sudo usermod -aG sudo ansibleuser

# For CentOS/RHEL, use the 'wheel' group:
# sudo usermod -aG wheel ansibleuser

  2. Configure passwordless sudo for the Ansible user (Highly Recommended for Automation): This allows Ansible to escalate privileges without being prompted for a password.

    # Open the sudoers file for editing
sudo visudo

# Add the following line at the end of the file, replacing 'ansibleuser' with your chosen user:
# ansibleuser ALL=(ALL) NOPASSWD: ALL

# Alternatively, for the 'sudo' group (if you added your user to it):
# %sudo ALL=(ALL) NOPASSWD: ALL
# (Ensure this line is not commented out if you use group-based sudo)

    Save and exit the visudo editor.

  3. Ensure SSH Key is deployed for the ansibleuser: If you’re using SSH keys (which you should be!), ensure the public key from your Ansible controller is in the ansibleuser’s ~/.ssh/authorized_keys file on the Droplet.

    # Switch to the new ansibleuser
sudo su - ansibleuser

# Create .ssh directory if it doesn't exist
mkdir -p ~/.ssh

# Set correct permissions
chmod 700 ~/.ssh

# Add your Ansible controller's public key (e.g., ~/.ssh/id_rsa.pub) to authorized_keys
# Use your preferred method: copy-paste, scp from controller, etc.
# Example (if you SCP'd the key to a temporary location):
# cat /tmp/id_rsa.pub >> ~/.ssh/authorized_keys

# Set correct permissions for authorized_keys
chmod 600 ~/.ssh/authorized_keys

# Verify key is present
cat ~/.ssh/authorized_keys

# Exit back to root or original user
exit

  4. Review PermitRootLogin in sshd_config (if trying to connect as root): If you must connect as root, ensure PermitRootLogin allows it.

    sudo vi /etc/ssh/sshd_config

    Look for PermitRootLogin.

    • If it’s no, you must connect as a non-root user.
    • If it’s prohibit-password, it will allow root login only with SSH keys. Ensure your Ansible key is deployed for root.
    • If you set it to yes (less secure, generally not recommended), ensure it’s allowed. After any changes to sshd_config, restart the SSH service:
    sudo systemctl restart sshd

3. Configuration Check

Now, let’s look at your Ansible controller’s configuration files.

On your Ansible Controller:

  1. Inventory File (e.g., hosts.ini): Ensure your inventory specifies the correct user, the intention to use sudo, and optionally the python interpreter path.

    [webservers]
your_droplet_ip ansible_user=ansibleuser ansible_become=yes ansible_become_method=sudo ansible_python_interpreter=/usr/bin/python3
    • your_droplet_ip: Replace with your Droplet’s actual IP address or hostname.
    • ansible_user=ansibleuser: Crucial! This tells Ansible to connect as the user you configured on the Droplet. Do not use root here unless you explicitly want to and have configured PermitRootLogin accordingly.
    • ansible_become=yes: Instructs Ansible to use privilege escalation (e.g., sudo).
    • ansible_become_method=sudo: Explicitly states sudo as the method. (This is the default, but good for clarity).
    • ansible_python_interpreter=/usr/bin/python3: DigitalOcean Droplets often use Python 3, and explicitly setting this can prevent issues.

    Note: If you did not configure NOPASSWD for sudo, you would also need ansible_become_pass='your_sudo_password' in your inventory or provide it via --ask-become-pass on the command line, which is not ideal for automation.

  2. Ansible Configuration File (ansible.cfg): This file, typically in the same directory as your playbooks or ~/.ansible.cfg, can set global defaults.

    [defaults]
# Path to your inventory file
inventory = ./hosts.ini

# Specify the default private key for SSH connections
private_key_file = ~/.ssh/id_rsa # Or the path to your specific private key

# (Optional) Default remote user if not specified in inventory
# remote_user = ansibleuser

[privilege_escalation]
become = True
become_method = sudo
# become_user = root # Uncomment if you always want to 'become' root
# become_ask_pass = False # Set to False if NOPASSWD is configured

    Ensure private_key_file correctly points to the SSH private key that corresponds to the public key you deployed on the Droplet.

4. Verification

After applying the fixes, perform these steps to confirm everything is working correctly:

  1. Manual SSH and sudo Test: From your Ansible controller, manually SSH into the Droplet using the ansibleuser:

    ssh ansibleuser@your_droplet_ip

    Once logged in:

    sudo whoami
    • Expected: It should return root without asking for a password. If it asks for a password, your NOPASSWD configuration is incorrect.
    • If sudo whoami works, try a simple file creation as root: 
      sudo touch /root/test_file_from_ansible
exit

  2. Ansible Ping Test: Use Ansible’s ping module, which is a good basic connectivity and privilege escalation test:

    ansible your_droplet_ip -m ping -i ./hosts.ini
    • Expected Success Output: 
      your_droplet_ip | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

    If this fails, you still have a fundamental connection or permission issue.

  3. Ansible Module Test Requiring Root Privileges: Try a simple task that requires sudo to ensure become is functioning.

    For Ubuntu/Debian Droplets:

    ansible your_droplet_ip -m apt -a "name=htop state=present" -i ./hosts.ini

    For CentOS/RHEL Droplets:

    ansible your_droplet_ip -m yum -a "name=htop state=present" -i ./hosts.ini
    • Expected Success: The command should run without errors, and htop should be installed on your Droplet.

By systematically going through these steps, you should be able to identify and resolve the underlying permission issues causing the “Ansible 403 Forbidden” error on your DigitalOcean Droplets, enabling smooth automation.

⚡ Related Troubleshooting Guides