$ pwd

[$ ] Tor Node 2 — Tor v3 hidden-service hosting (Iceland, Romania, Monero)

// NAME

tor-2 — Mid-tier onion hosting for active hidden services — 2 vCPU, 4 GB RAM.

// SYNOPSIS

xmrhost-cli provision --plan=tor-2 --region=<is|ro>

// SPEC

$ xmrhost-cli spec --plan=tor-2

cpu 2 vCPU

ram 4 GB DDR4

storage 50 GB NVMe SSD

bandwidth 1 Gbps egress (metered on tor exit, unmetered intra-tor)

virtualization KVM

os Debian 12 + tor LTS, Whonix Gateway template

// NOTES

Recommended for matrix homeserver behind .onion, mid-traffic forums
2 onion-auth client keys provisioned by default

// REGIONS

$ xmrhost-cli regions --plan=tor-2

region country ping flag

is Iceland (Reykjavik) ~38ms FRA --region=is

ro Romania (Bucharest) ~28ms FRA --region=ro

// ORDER

monthly +30% $55

annual -20% $403

biennial -25% $756

$ order tor-2

// no-kyc crypto billing (xmr recommended; btc / ltn / ltc / eth / usdt accepted) — why-monero covers the rationale, payments the flow.

// DESCRIPTION

Tor v3 onion-only hosting

Every Tor node ships with a hardened tor.conf, no clearnet listener, and sshd reachable only via onion-auth (rend-spec-v3 §G.5). The shape is opinionated on purpose: a Tor hidden-service VPS that exposes a clearnet sshd is a Tor hidden-service VPS waiting to be deanonymised by traffic correlation.

// pre-configured defaults

Tor LTS package pinned, ExitPolicy reject *:*, HardwareAccel 1, SafeLogging 1
sshd: PasswordAuthentication no, PermitRootLogin no, fail2ban active, port 22 unbound from clearnet
Onion-auth client keys provisioned at order; recovery key sealed in your offline store
vanity .onion address (≤ 8 chars) generated with mkp224o, included on tor-1+
Whonix-Gateway template available as an alternative OS — strict-isolation for the paranoid
auditd + unattended-upgrades on; grsec / KSPP-baseline kernel patches applied

We don't run exits from these tiers — exit-relay operation is a different legal posture and the brand offers Lokinet for the exit-flavoured workload. These are tuned for hidden services and non-exit middle relays. If you want to add a relay role on top, the manual covers the exact tor.conf delta.

// see also

// PROVISIONING

after you click order

$ xmrhost-cli provision --plan=tor-2 --region=is
[ok] reserving capacity in region=is
[ok] node allocated: tor-2-is-45
[ok] applying hardened-by-default profile (sshd, fail2ban, unattended-upgrades)
[ok] generating .onion v3 address (mkp224o, ≤8 chars vanity)
[ok] handoff key sealed → view via the console at /console
provisioned in 47s. ssh access via onion-auth or wireguard, your choice.

// you receive the onion-auth key + initial sshd config in the same handoff. no email-shipped credentials. nothing is logged to the operator side.

// HARDENING BASELINE — WHAT SHIPS BY DEFAULT

$ cat /etc/xmrhost/baseline.d/*

Every Tor Node 2 ships with the xmrhost hardening baseline applied on the first boot — no opt-in flag, no add-on, no separate purchase. The baseline is the same across the catalog (vps / dedicated / gpu / tor / i2p / lokinet); category-specific extras are listed below the common section. Detailed per-control runbooks live in /docs; the cross-cutting overview is at /hardening.

KERNEL. KSPP-baseline sysctls applied (kernel.kptr_restrict=2, kernel.yama.ptrace_scope=1, kernel.unprivileged_bpf_disabled=1, vm.unprivileged_userfaultfd=0, net.ipv4.tcp_syncookies=1, +12 more), unprivileged user-namespace creation gated, kexec disabled at runtime. Full list and rationale: /docs/kernel-hardening-checklist.
SSHD. PasswordAuthentication no, ChallengeResponseAuthentication no, KbdInteractiveAuthentication no, PermitRootLogin prohibit-password, MaxAuthTries 3, Ed25519-only host keys (RSA host keys removed), legacy KEX / cipher / MAC families disabled. fail2ban preconfigured with the sshd-default ruleset. Runbook: /docs/harden-sshd; key migration: /docs/ssh-key-migration.
AUDIT. auditd enabled with the laurel-compatible default ruleset (auth, identity, network-config, time-change, mount, perm-mod). unattended-upgrades on for main/security only — feature releases stay operator-controlled. systemd-journald persistent storage with SystemMaxUse=512M.
NETWORK. Egress-default-permit (the box reaches the internet), ingress-default-deny (only sshd + the customer's declared services). Outbound port 25 (SMTP) closed by default; customers operating a real MTA request the lift via /contact with the reverse-DNS pointing to a domain they control. Dual-stack IPv4 + IPv6 (/64 routed). RIPE- allocated PI on Iceland and Romania.
MONITORING. node_exporter (Prometheus textfile exporter) listening on 127.0.0.1:9100 — the operator's monitoring scrapes via wireguard from the management VLAN, never from the public internet. Customers wanting their own metrics tap add a second exporter on a private interface.
TOR PRECONFIG. v3 hidden service already running, .onion delivered at provisioning, mkp224o vanity (≤ 8 chars) included, sshd reachable only via onion v3 onion-auth (rend-spec-v3 §G). Runbook: /docs/provision-tor-hidden-service.

// the baseline is editorial-stable — when the operator changes a default, the change is logged in /notes with the rationale and the migration notes for boxes already in service. /hardening is the canonical pillar; /docs is the procedural manual.

// RECOMMENDED PLAYBOOKS

$ grep -l 'tor-2' /usr/share/doc/xmrhost/playbook/

/playbook/tor-relay — operate a tor middle/exit relay or obfs4 bridge with bgp-stable uplinks and a sane abuse posture
/playbook/forum — discourse / lemmy / phpbb at offshore latency — narrow-takedown jurisprudence and no first-strike termination
/playbook/journalism — source-protection-grade hosting for newsrooms, leak inboxes, and securedrop / hush line intake

// FAQ

$ faq -p tor-2

Q.Is the .onion preconfigured at provisioning?

A.Yes. The tor-* tiers ship with a v3 hidden service already configured in /etc/tor/torrc and the corresponding HiddenServiceDir already populated with a freshly generated Ed25519 keypair. The .onion address is delivered to the customer at provisioning via the order receipt. Vanity-prefix .onion (mkp224o, capped at 8 characters) is included on tor-1 and above.

Q.Why is sshd not on a clearnet port on Tor tiers?

A.Co-hosting a clearnet sshd with a v3 hidden service creates a traffic-correlation attack against the service: an adversary that knows the .onion can probe the box's clearnet IPv4 for sshd uptime + load + traffic patterns and correlate. The tor-* tiers reach sshd via onion v3 onion-auth (rend-spec-v3 §G); no clearnet listener exists. Documented at /docs/provision-tor-hidden-service.

Q.Can I host a clearnet site alongside the .onion?

A.Not on the tor-* tiers — those are onion-only. If a customer needs clearnet + .onion on the same box, the right pick is a vps-* tier with a separately configured Tor service (the runbook is at /docs/provision-tor-hidden-service). The split keeps the tor-* tiers' threat-model commitment honest: "if it's tor-1, there is no clearnet listener" is a property the operator can preserve.

Q.Where is the Tor hosting located?

A.Iceland (Reykjavik, RIPE) or Romania (Bucharest, RIPE). Iceland is the recommended pick for hidden services that the operator considers high-stakes (Höfundalög nr. 73/1972 lacks a takedown-without-court-order procedure); Romania is also supported (Legea 8/1996). The full jurisdictional comparison: /vs/iceland-vs-romania-offshore-jurisdiction.

Q.Is the operator running a Tor relay alongside my hidden service?

A.No — the tor-* tiers run a Tor client + hidden service only, not a relay. Co-locating a relay on the same box does not improve hidden-service anonymity (the rendezvous protocol does not involve the local relay) and adds attack surface. If a customer wants to run a non-exit relay separately, the right pick is a vps-* tier and the runbook at /docs/run-non-exit-tor-relay.

Q.Do you accept abuse complaints addressed to the .onion?

A.The operator does NOT run an abuse-report intake — third-party complaints (DMCA-format notices, informal takedown requests, brand-monitoring claims) receive no action and no acknowledgement. Tenant enforcement under the AUP (/legal/aup) is operator-discretion based on the operator's own observations, not on third-party reports. The only inbound legal channel is a court-issued order from a competent tribunal under Iceland Höfundalög nr. 73/1972 or Romania Legea nr. 8/1996, processed by counsel — not via this surface. CSAM is the explicit hard-prohibition; the operator detects it via its own controls.