oxeo0/blog-contributions
1
0
Fork 0
mirror of http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/nihilist/blog-contributions.git synced 2025-07-02 06:46:42 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

update anonymousremoteserver

Browse source
This commit is contained in:
midas 2025-02-12 16:06:07 +01:00
parent d30bb4e898
commit 5fd03e25e9
1 changed files with 65 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

73
opsec/anonymousremoteserver/index.html
View file

@ -152,23 +152,80 @@ ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHqt0O2ZbRt/7ikk0PdPRcb1GRBE5YNDdBHFCMGIdeHb
<div class="container">
<div class="row">
<div class="col-lg-8 col-lg-offset-2">
<h1><b>Power tools</b></h1>
Before getting started let's review our tools and reminds ourselves of the security implications of their use:
<ul>
<li>Tor: if you're reading this, you already know what it is.<br>
<b>Risks:</b>
<ul>
<li> 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 </li>
</ul>
</li>
<li> 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.
<br>
<b>Risks</b>
<ul>
<li>Authentication: the first time you connect to a server you should check its host key fingerprint. This is <b>NOT</b> 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.</li>
<li>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. </li>
<li>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 <b>try every key it has until succeeding when connecting to a server</b>. 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.</li>
</ul>
</li>
<li>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</li>
</ul>
<h2><b>Accessing the server anonymously (SSH through Tor)</b></h2> </br> </br>
<p>To access the server anonymously, you just need to ssh there through tor using torsocks:</p>
<h3>Setting up your onion service</h3>
That one is easy! Connect to your server using your provider's web shell and edit your torrc so it looks like this:
<p>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: </p>
<pre><code class="nim">
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
</code></pre>
<br><br>
Restart tor with <i>sudo systemctl restart tor</i><br>
to find your hidden service hostname:
<pre><code class="nim">
sudo cat /var/lib/tor/onion/tor-ssh/hostname
</code></pre>
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:
<pre><code class="nim">
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
</code></pre>
<pre><code class="nim">
[ mainpc ] [ /dev/pts/6 ] [~]
→ cat .ssh/config| head -n4
→ cat .ssh/config| head -n5
Host test-server
User root
hostname 185.216.68.156
IdentityFile ~/.ssh/id_ed25519
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 ] [~]
→ torsocks ssh test-server
The authenticity of host '185.216.68.156 (185.216.68.156)' can't be established.
→ 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 '185.216.68.156' (ED25519) to the list of known hosts.
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;