en
Ansible Automation for Tor Hidden Service Infrastructure
Managing multiple Tor hidden services manually becomes error-prone and time-consuming at scale. Ansible's agentless automation model - connecting to servers via SSH and applying declarative configuration - is well-suited to .onion infrastructure management. Ansible playbooks can provision new hidden services, apply security hardening consistently across servers, update Tor configurations, and manage certificate and key rotation - all through SSH connections routed over Tor. Infrastructure-as-code for .onion services provides: consistent configuration across servers, documented server state in version-controlled playbooks, faster deployment of new services, and reliable rollback when configurations need to be reverted.
Need this done for your project?
We implement, you ship. Async, documented, done in days.
Ansible SSH Configuration for .onion Servers
Ansible connects to managed servers via SSH. For .onion servers, SSH connections must route through Tor. Configure Ansible's SSH ProxyCommand for .onion hosts in the Ansible inventory. In ansible.cfg or inventory file: add ansible_ssh_common_args='-o ProxyCommand="nc -x 127.0.0.1:9050 %h %p"' for .onion hosts. Create an inventory group [onion_servers] with your .onion hostnames and this ProxyCommand. Test connectivity: ansible onion_servers -m ping - should return pong from each .onion server. SSH key authentication is required for Ansible's password-free operation: ensure your Ansible controller's SSH public key is in the target server's authorized_keys. For the highest security, use a dedicated Ansible SSH key pair (not your personal admin key) with limited permissions on the managed servers.
Playbook: Tor Hidden Service Provisioning
A provisioning playbook installs and configures Tor with a new hidden service. Key tasks: (1) Install Tor: apt module, name: tor. (2) Create HiddenServiceDir: file module, path: /var/lib/tor/myservice/, state: directory, owner: debian-tor, mode: '0700'. (3) Configure torrc: template module, src: torrc.j2, dest: /etc/tor/torrc, notify: Restart Tor. The torrc.j2 template uses Jinja2 variables for customizable HiddenServicePort mappings. (4) Service module: name: tor, state: started, enabled: yes. (5) Read generated .onion address: slurp module reads /var/lib/tor/myservice/hostname, register as onion_hostname. (6) Output .onion address: debug module shows the generated address. After the play completes, the server's .onion address is displayed and the key files are created at the standard path.
Playbook: Nginx Configuration for .onion Services
Configure Nginx to serve the .onion application. Template module deploys Nginx config from a Jinja2 template. The nginx_onion.conf.j2 template: server { listen 127.0.0.1:{{ nginx_port }}; server_name localhost; root {{ app_root }}; location / { proxy_pass http://127.0.0.1:{{ app_port }}; proxy_set_header Host $host; } access_log off; }. Variables nginx_port, app_root, and app_port are defined in the inventory or group_vars. Handler task: when notified by the template task, run nginx -t (validate config) and nginx -s reload. Include SSL termination if the application needs HTTPS internally (though .onion services provide transport encryption at the Tor circuit layer, making SSL optional for the application layer). Apply handlers in the correct order: Tor restart before Nginx reload to ensure the .onion address is known.
Security Hardening Playbook
A security hardening playbook applies consistent baseline security across all .onion servers. Tasks: (1) SSH hardening: replace sshd_config with a hardened template disabling password auth, root login, and unused features. (2) Unattended upgrades: configure automatic security updates. (3) Fail2ban: install and configure fail2ban with rules for SSH brute force. (4) Tor logging: configure Tor's LogLevel notice (not debug or info to minimize log data). (5) Kernel hardening: deploy sysctl settings disabling IP forwarding, enabling ASLR, and hardening network settings. (6) File permissions: verify critical Tor key file permissions are 700 with debian-tor ownership. Run the hardening playbook against all new servers as part of the provisioning workflow, and periodically as a compliance check against existing servers.
Idempotency and Configuration Drift Management
Ansible's idempotency means running a playbook multiple times has the same effect as running it once - it only makes changes when the current state differs from the desired state. For .onion infrastructure: run playbooks regularly (daily or weekly) to detect and remediate configuration drift. Use Ansible's check mode: ansible-playbook playbook.yml --check shows what changes would be made without applying them. Differences between actual state and desired state indicate drift. For Tor key files: never overwrite existing key files with the provisioning playbook (use creates: /var/lib/tor/myservice/hostname in the task's conditional to skip key generation if keys exist). Overwriting Tor keys would change the .onion address, losing all links and bookmarks to the service.
Related Services
Why Anubiz Host
100% async — no calls, no meetings
Delivered in days, not weeks
Full documentation included
Production-grade from day one
Security-first approach
Post-delivery support included
Ready to get started?
Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.