Tor and Monero Series - Part 2 - Running a Private Monero Remote Node over Tor (with Client Authorization)

· linux, unix, security, tor, monero · 4 min read

Introduction

Many Monero users either connect their wallets to public remote nodes or run a full node on every machine they own. Both approaches are unnecessary and come with real privacy and operational downsides.

Public nodes can:

  • log metadata
  • selectively censor requests
  • correlate wallet activity

Running multiple full nodes:

  • wastes disk space
  • increases maintenance
  • encourages poor security shortcuts

This post shows how to run one authoritative Monero node on a workstation and access it securely from a laptop over Tor, without exposing RPC to the LAN or clearnet, and without trusting third parties.

Access to the node is cryptographically restricted using Tor v3 client authorization.

Prerequisite:
This post assumes you already have a working Tor client as described in
“A Secure Tor Client Setup on Artix Linux (runit)”.
If not, read that first.

Threat Model and Scope

This setup is designed to protect against:

  • Public RPC exposure
  • ISP or network-level observation
  • Malicious or logging public nodes
  • Accidental LAN access
  • Unauthorized clients connecting to your node

This setup does not protect against:

  • A compromised workstation or laptop
  • Malware stealing wallet keys
  • Physical access attacks
  • Poor wallet operational hygiene

The goal is private, authenticated access to your own Monero node — not absolute anonymity.

Architecture Overview

Workstation (Node Host)

  • Runs monerod
  • Stores the full blockchain
  • RPC bound to 127.0.0.1 only
  • Exposes RPC via a Tor v3 hidden service
  • Enforces client authorization at the Tor layer

Laptop (Wallet Client)

  • Runs Monero GUI (primary) or CLI (optional)
  • Stores no blockchain
  • Connects to the node over Tor SOCKS
  • Authenticates using Tor client authorization
Laptop (wallet)
   |
   |  Tor SOCKS + client auth
   v
Tor Network
   |
   v
Workstation (monerod)
RPC: 127.0.0.1:18081

Workstation: Monero Node Setup

Install Monero:

sudo pacman -S monero

Create a dedicated data directory:

sudo mkdir -p /var/lib/monero
sudo chown monero:monero /var/lib/monero
sudo chmod 700 /var/lib/monero

Example monerod.conf:

data-dir=/var/lib/monero
rpc-bind-ip=127.0.0.1
rpc-bind-port=18081
restricted-rpc=1
confirm-external-bind=1

Run monerod as a service (Artix/runit users can adapt this to their setup).

Verify locally:

ss -ltnp | grep 18081

You should only see 127.0.0.1:18081.

Workstation: Tor Hidden Service for RPC

Edit /etc/tor/torrc on the workstation and add:

HiddenServiceDir /var/lib/tor/monero-rpc
HiddenServiceVersion 3
HiddenServicePort 18081 127.0.0.1:18081

Restart Tor:

sudo sv restart tor

Retrieve the onion address:

sudo cat /var/lib/tor/monero-rpc/hostname

At this stage, the service is reachable over Tor, but not yet access-controlled.

Laptop: Wallet as a Thin Client

Monero GUI (Primary)

In Settings → Node:

  • Enable Remote node
  • Address: <your-onion-address>
  • Port: 18081
  • SOCKS proxy IP: 127.0.0.1
  • SOCKS proxy port: 9062 (isolated port from Post 1)
  • Enable Trusted daemon

Restart the GUI after applying changes.

Monero CLI (Optional)

monero-wallet-cli \
  --daemon-address <your-onion-address>:18081 \
  --proxy 127.0.0.1:9062 \
  --trusted-daemon

The laptop will not download the blockchain. Any “syncing” shown is wallet scanning, not node synchronization.

Why Onion Addresses Are Not Access Control

An onion address identifies a service — it does not authenticate clients.

If someone obtains the onion address:

  • they can attempt connections
  • they can brute-force RPC credentials
  • they can consume resources

RPC usernames and passwords provide weak protection and operate after the connection is established.

Proper access control must happen at the Tor layer, before traffic reaches monerod.

Tor v3 Client Authorization

Tor v3 client authorization restricts access using public-key cryptography.

  • The hidden service maintains an allow-list of client public keys
  • Clients present a corresponding private key
  • Unauthorized clients are silently dropped
  • monerod never sees unauthorized traffic

This is strong, clean access control.

Implementing Client Authorization

Workstation: Authorize the Laptop

Generate a client keypair and create an authorization file in:

/var/lib/tor/monero-rpc/authorized_clients/

The file format is:

descriptor:x25519:<client-public-key>

Restart Tor after adding the file.

Laptop: Install the Client Key

Ensure the client auth directory exists:

sudo mkdir -p /var/lib/tor/onion_auth
sudo chown tor:tor /var/lib/tor/onion_auth
sudo chmod 700 /var/lib/tor/onion_auth

Install the client key in:

/var/lib/tor/onion_auth/<name>.auth_private

Restart Tor on the laptop:

sudo sv restart tor

Verification and Enforcement

Test access from the laptop:

curl --socks5-hostname 127.0.0.1:9062 \
  http://<your-onion-address>:18081/get_info

You should receive JSON output.

Remove the client key temporarily and restart Tor. The connection should now fail.

Restore the key and restart Tor again. Access should return.

Operational Notes

  • Back up the client authorization key securely
  • Adding another client repeats the same process
  • Revoking access is as simple as removing the server-side auth file
  • Tor or Monero restarts do not affect authorization
  • If the workstation is offline, wallets cannot connect

What This Setup Does Not Do

This setup does not:

  • Make Monero perfectly anonymous
  • Protect against compromised wallets
  • Replace good key management
  • Eliminate the need for operational discipline

It provides private, authenticated access to your own node — nothing more and nothing less.

Summary

  • One authoritative Monero node
  • No public RPC exposure
  • No duplicated blockchain
  • Tor-only transport
  • Cryptographically enforced access control

This approach is simple, robust, and scales cleanly if you later add more authorized clients.