Previous Page

nihilist@mainpc - 2024-05-02

Acquiring remote servers anonymously (non-KYC providers)

Finding out a non-KYC Cloud Provider and Email Provider

As we discussed previously, KYC is out of the question if you want to remain anonymous. So you need to find a cloud provider that allows you to rent servers without any KYC.

To find one you can go on kycnot.me:

the current one I use for my services is ServersGuru, as they can resell popular cloud providers like hetzner.

In our example below we'll use Cockbox. but first thing we need is a non-KYC email provider, to do so we could follow Privacy Guides' recommendation and create an account on Tuta, but for simplicity i'll use a temporary email from https://tmail.link (do not use it for extended usage)

Now that the account is created, we can also validate if we can receive mails:

Purchasing the server anonymously (using Monero)

Next we generate a SSH key to connect to the server:

[ mainpc ] [ /dev/pts/5 ] [~]
→ ssh-keygen -t ed25519 -C ""
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/nihilist/.ssh/id_ed25519): /home/nihilist/.ssh/ssh-key-test
/home/nihilist/.ssh/ssh-key-test already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/nihilist/.ssh/ssh-key-test
Your public key has been saved in /home/nihilist/.ssh/ssh-key-test.pub
The key fingerprint is:
SHA256:hu1aO2qMU0XuaRDTRiVHH3Jl2hNP/0prlAnpPCTGECo
The key's randomart image is:
+--[ED25519 256]--+
|       o=+= o.+ .|
|      o.+= + * +.|
|    E .*  + * o o|
|     ..oo. = . +.|
|      .+S.  + = .|
|      .o+    + o |
|     + .o     +  |
|    o oo..   .   |
|     oo...       |
+----[SHA256]-----+

[ mainpc ] [ /dev/pts/5 ] [~]
→ cat .ssh/ssh-key-test.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHqt0O2ZbRt/7ikk0PdPRcb1GRBE5YNDdBHFCMGIdeHb

validate the VPS purchase with the Monero option:

Then here we send the Monero payment:

then wait 10-20 minutes for the payment to be validated by the network, and then you should recieve the mail with your server accesses:

Now that the server is provisionned, we can connect to it:

Power tools

Before getting started let's review our tools and reminds ourselves of the security implications of their use:

• Tor: if you're reading this, you already know what it is.
  Risks:
  • Information leakage: if you try to resolve "mysecretillegalhostingserver.onion" against your ISP's DNS server it will leave an incriminating log: unless your server is well-known and has a lot of traffic you can't really justify knowing it's onion address
• SSH: Secure SHell. This tools allows you to connect to a remote server with an encrypted tunnel, this providing you with confidentiality when doing administration tasks.
  Risks
  • Authentication: the first time you connect to a server you should check its host key fingerprint. This is NOT an issue in our case since tor will provide another couple of layers of authentication. If you connect on a clearweb server through tor though you will want to check the host key fingerprint to make sure your exit node isn't trying to MITM you.
  • Password security: Nefarious operators trawl through the web on a daily basis trying credential stuffing attacks (logging into your server with weak/well known passwords), if you set up root:toor as a login you will get compromised quickly.
  • Information leakage: instead of setting up a password you decide to do things more securely and use an ssh key as a mean of authentication. By default, the ssh client will try every key it has until succeeding when connecting to a server. Why is that bad? Say your cloud provider decides to log verbosely your VPS' ssh server connection. When you connect next they might get a bunch of public keys that you use on other services. If Leo decides to ask github if anyone is using any of those keys to, say, push code to repositories or deploy stuff through actions then they will have a link between your github account and your onion server. Let's hope you haven't set up a personal email with github, because if you did, you're toast.
• Socat: socat allows you to establish two bidirectional byte streams and transfer data between them. Anything goes, you can link unix socket to tcp sockets or whatever strikes your fancy. In this case we will use it to create a socks5-looking bridge for SSH to use when connecting to our remote server

Accessing the server anonymously (SSH through Tor)

Setting up your onion service

That one is easy! Connect to your server using your provider's web shell and edit your torrc so it looks like this:

To access the server anonymously, you need to configure SSH to use tor and only your chosen key (modify your ~/.ssh/config so it looks like this:

AutomapHostsSuffixes .onion,.exit
DataDirectory /var/lib/tor
ExitPolicy reject *:*
PublishServerDescriptor 0
SOCKSPort 127.0.0.1:9050 IsolateDestAddr
HiddenServiceDir /var/lib/tor/onion/tor-ssh
HiddenServicePort 22
    

Restart tor with sudo systemctl restart tor
to find your hidden service hostname:

    sudo  cat /var/lib/tor/onion/tor-ssh/hostname
    

Next we are going to setup and harden our client ~/.ssh/config so even if we make a mistake and try reaching our server without tor being connected we won't leak anything:

Host test-server
  HostName hostnamefromprevi0us5t3p.onion
  ProxyCommand socat - SOCKS4A:localhost:%h:%p,socksport=9050 # tells ssh to proxy the connection through tor
  IdentityFile ~/.ssh/ssh-key-test
  IdentitiesOnly yes                                          # only use the identityFile we configured and don't try any other

[ mainpc ] [ /dev/pts/6 ] [~]
→ cat .ssh/config| head -n5
Host test-server
  HostName hostnamefromprevi0us5t3p.onion
  ProxyCommand socat - SOCKS4A:localhost:%h:%p,socksport=9050 # tells ssh to proxy the connection through tor
  IdentityFile ~/.ssh/ssh-key-test
  IdentitiesOnly yes                                          # only use the identityFile we configured and don't try any other

[ mainpc ] [ /dev/pts/6 ] [~]
→ ssh root@test-server
The authenticity of host 'hostnamefromprevi0us5t3p.onion' can't be established.
ED25519 key fingerprint is SHA256:Od5FT4wcALDHXXK2B4t6lM8idsDmUfhqWpDFjStgBwI.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added  'hostnamefromprevi0us5t3p.onion'(ED25519) to the list of known hosts.
Linux cockbox 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

root@cockbox:~# id
uid=0(root) gid=0(root) groups=0(root)

root@cockbox:~# apt update -y ; apt upgrade -y ; apt autoremove -y
	

And that's it! We now have access to a remote server, we acquired it anonymously, and are now using it anonymously as well.