Buy and manage a VPS entirely over Tor: onion checkout, SSH through Tor, and an onion address for SSH

Why do it all over Tor

Paying without an account removes your identity from the billing side. Your IP address is the other half: the address that ordered the server, that reads the access page and that opens SSH sessions is logged somewhere along the way, as it is for every connection on the internet. If the point of the server is that it is not attributable to you, those connections should come from the Tor network rather than from your home or office.

BitVPS is built for this rather than merely tolerating it. The whole site runs as a v3 onion service, Tor exit nodes are not challenged or blocked on the clearnet domain, and every access-link email includes an onion version of the link. This guide goes from ordering to a server that you only ever touch through Tor.

Order from the onion mirror

• Install Tor Browser from torproject.org and open the onion address shown in the site footer (it ends in .onion and is also linked from the FAQ). The clearnet domain works over Tor too; the onion address just skips the exit node entirely.
• Configure a server as usual: plan, location, OS, SSH key, days, payment method. Paste a public key generated for this server (see the anonymous-VPS guide for key hygiene).
• Pay. Monero is the natural pairing with Tor; the payment page is served by the processor on the clearnet and opens fine in Tor Browser.
• Use an email mailbox you can read over Tor. Several privacy-focused mail providers have onion services; a webmail you only ever open in Tor Browser keeps the whole trail inside the network.
• The access-link email contains two links: the clearnet one and an onion one. Use the onion link in Tor Browser for the access page, console, reinstall and extension.

SSH to the server through Tor

Tor Browser runs a SOCKS proxy on 127.0.0.1:9150 while it is open; a system Tor daemon (apt install tor) listens on 9050. Either one can carry SSH. The OpenBSD netcat shipped with Debian and Ubuntu speaks SOCKS5 directly, so no extra tools are needed.

# One-off, via the system tor daemon on 9050 (use 9150 for Tor Browser):
ssh -o ProxyCommand='nc -X 5 -x 127.0.0.1:9050 %h %p' -i ~/.ssh/anon_server [email protected]

# Permanent, in ~/.ssh/config:
cat >> ~/.ssh/config <<'EOF'
Host anon
    HostName YOUR.SERVER.IP
    User root
    IdentityFile ~/.ssh/anon_server
    IdentitiesOnly yes
    ProxyCommand nc -X 5 -x 127.0.0.1:9050 %h %p
EOF
ssh anon

The first connection asks you to confirm the host key fingerprint. Over Tor this matters more than usual because an exit node sits between you and the server. Open the browser console from the access page and run the command below on the server, then compare the fingerprint with the one SSH shows you.

# In the browser console on the server:
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Latency through Tor is typically 300 to 800 ms, which is noticeable in an interactive shell but fine. Use mosh if you want it to feel snappier; it needs a UDP port open and does not work through Tor, so it is only an option if you are happy to reach the clearnet IP directly. For file transfer, scp and rsync inherit the ProxyCommand from your SSH config automatically.

Give the server an onion address for SSH

Connecting through an exit node still means your SSH session exits Tor and crosses the public internet to the server’s IP. Running an onion service for SSH on the server keeps the whole path inside Tor, authenticates the server by its address (the address is the public key, so there is no fingerprint to trust on first use) and lets you close port 22 on the public interface entirely.

# On the server:
apt install -y tor
cat >> /etc/tor/torrc <<'EOF'
SocksPort 0
HiddenServiceDir /var/lib/tor/ssh/
HiddenServiceVersion 3
HiddenServicePort 22 127.0.0.1:22
EOF
systemctl restart tor
cat /var/lib/tor/ssh/hostname      # e.g. abc...xyz.onion

# On your machine, add a second host entry that uses the onion address:
cat >> ~/.ssh/config <<'EOF'
Host anon-onion
    HostName abc...xyz.onion
    User root
    IdentityFile ~/.ssh/anon_server
    IdentitiesOnly yes
    ProxyCommand nc -X 5 -x 127.0.0.1:9050 %h %p
EOF
ssh anon-onion

Once that works reliably, you can stop exposing SSH on the public IP. Keep the console as your fallback and do this in two steps so a typo cannot lock you out.

# Step 1: restrict clearnet SSH to a single address you control (optional half-way house).
ufw delete allow OpenSSH
ufw allow from YOUR.OTHER.IP to any port 22 proto tcp

# Step 2 (onion-only): bind sshd to localhost so only tor can reach it.
# Ubuntu 24.04 starts sshd through ssh.socket, which ignores ListenAddress,
# so switch to the plain service first.
systemctl disable --now ssh.socket
systemctl enable ssh.service
cat > /etc/ssh/sshd_config.d/10-onion-only.conf <<'EOF'
ListenAddress 127.0.0.1
EOF
sshd -t && systemctl restart ssh
ufw delete allow from YOUR.OTHER.IP to any port 22 proto tcp
ss -ltnp | grep sshd      # should show 127.0.0.1:22 only

Optional: client authorization for the SSH onion

A v3 onion address can be made unreachable to anyone who does not hold a client key, which hides even the existence of the SSH service from someone who learns the address. Generate an x25519 key pair on your machine, put the public half in the service’s authorized_clients directory, and configure your local tor with the private half.

# On your machine (openssl plus the coreutils base32 tool):
openssl genpkey -algorithm x25519 -out client.key.pem
PRIV=$(openssl pkey -in client.key.pem -outform DER | tail -c 32 | base32 | tr -d '=')
PUB=$(openssl pkey -in client.key.pem -pubout -outform DER | tail -c 32 | base32 | tr -d '=')
echo "descriptor:x25519:$PUB"      # goes on the server
echo "ONIONADDR_WITHOUT_SUFFIX:descriptor:x25519:$PRIV"   # goes in your local tor

# On the server:
install -d -m 0700 -o debian-tor -g debian-tor /var/lib/tor/ssh/authorized_clients
echo "descriptor:x25519:$PUB" > /var/lib/tor/ssh/authorized_clients/laptop.auth
chown debian-tor:debian-tor /var/lib/tor/ssh/authorized_clients/laptop.auth
systemctl reload tor

# On your machine, in /etc/tor/torrc:
#   ClientOnionAuthDir /var/lib/tor/onion_auth
# then write ONIONADDR_WITHOUT_SUFFIX:descriptor:x25519:$PRIV into
# /var/lib/tor/onion_auth/anon.auth_private and restart tor.

Everyday operations over Tor

• Extending, reinstalling, add-ons and the console: use the onion link from your access email. Request a new link from the login page in Tor Browser if you have lost it; it goes to the same mailbox.
• Package updates from the server itself go out over the server’s clearnet connection, which is normal: the server is not anonymous, you are. If you want apt to use Tor as well, apt install apt-transport-tor and switch the sources to tor+https:// URLs.
• Time: Tor needs a roughly correct clock on both ends. Keep systemd-timesyncd enabled on the server and do not fake the time zone on the client.
• Web services on the server for your own use are best exposed as onion services too, following the hidden-service guide, rather than opened on the public IP.

Which plan to pick

Tor adds no load worth sizing for. The entry plans (2 vCPU, 4 GB RAM, 40 GB NVMe from about $10/mo) are the right size for a server you administer over Tor and use for a VPN, relay, onion site or small application. Location matters little when every connection arrives through the Tor network; pick the jurisdiction you prefer. Configure a server from the onion mirror, pay in Monero or Bitcoin, and the access link arrives with its onion version included.