🛡️ Secure transports

🧅 Tor Onion

Tor anonymity network. For secure remote access using onion services and (optionally) for proxying bitcoind.

Onion services provide strong encryption and mutual authentication established based on information embedded into the .onion hostname. It does not require setting up port forwarding.

The onion service files, including secret key material, will be kept in /data/tor-hsv. If you lose them you'll lose your .onion address.

Setting up

Start with TOR=1. The .onion hostname will be shown on startup.

You'll be able to access your server through the .onion address from any client device with Tor installed, like the Tor Browser for desktop or Orbot for Android.

Non-anonymous mode

You can set TOR_NONANONYMOUS=1 to use the single-hop non-anonymous mode. This will remove the 3 extra hops that protect the server's anonymity, making the connection faster and more reliable. Clients will remain anonymous. Note that this is incompatible with BITCOIND_TOR.

Options

• TOR=0 (disabled by default, set to 1 to enable)
• TOR_NONANONYMOUS=0 (enable non-anonymous mode)
• TOR_CONFIG=<none> (custom config to append to torrc)
• TOR_LOGS=0 (display tor's logs in the docker run output)
• BITCOIND_TOR=0 (connect to the bitcoin network through tor)
• BITCOIND_RPC_ONION=0 (expose the bitcoind rpc port over onion)

Paths

• /data/tor-hsv (onion service files)

🐻 Dropbear SSH

Lightweight SSH server powered by Dropbear. For secure remote access via SSH tunnels, using public-key based authentication.

A pair of client and server keys will be generated for you by default. The client's private key that can be used to login will be available in /data/ssh-keys/client_rsa.

If you already have a client key that you'd like to use, you can mount the pubkey file into /root/id.pub (e.g. -v ~/.ssh/id_rsa.pub:/root/id.pub), or mount an authorized_keys file into /root/.ssh/authorized_keys.

By default, the SSH server permits port tunneling only. Set SSHD=UNRESTRICTED to enable shell access, X11 forwarding, agent forwarding and remote port forwarding.

Server set-up

Set SSHD=1, publish the SSH port (2222) for remote access and give the container an hostname (to make its virtual IP address easily discoverable from the client).

(server)$ docker run -p 2222:2222 --hostname ez -it ... eznode/eznode SSHD=1

Client set-up

Copy the generated client key file from ~/eznode/ssh-keys/client_rsa on the server to the client machine and setup an SSH tunnel:

(client)$ ssh -i ./client_rsa -fTN -L 50001:ez:50001 -p 2222 root@mynode.com

You will now be able to access the remote Electrum server through localhost:50001 on the client.

Protip: Use autossh to automatically restart dropped connections.

Android setup with ConnectBot

Punch through NATs with a reverse SSH tunnel

If you're unable to directly accept incoming connections to your server, you can create a reverse tunnel to route traffic through a different server that can.

The server can be any cheap VPS. It doesn't need to run anything apart from an SSH server. It won't see anything apart from encrypted traffic and IP addresses. You will be safe from MITM attacks, as long as you verify the fingerprint the first time you connect.

Match User satoshi
  GatewayPorts clientspecified

ssh -fTN -R :2222:localhost:2222 satoshi@cheapvps.com

Options

• SSHD=0 (disabled by default, set to 1 or UNRESTRICTED to enable)
• SSHD_LOGS=0 (display dropbear's logs in the docker run output)
• DROPBEAR_OPTS=<none> (custom CLI options for dropbear)

Paths

• /root/id.pub /root/.ssh/authorized_keys (mount from host to use existing client key)
• /data/ssh-keys/client_rsa (generated client key)
• /data/ssh-keys/host_rsa (generate host key)

Ports

• 2222

🔐 NGINX SSL

NGINX-powered SSL terminating reverse proxy.

To setup, set SSL=1, publish the SSL port and make sure to enable password-based authentication for the web services:

docker run -it -p 443:3443 ... eznode/eznode SSL=1 AUTH_TOKEN=mySecretPassword

A private key and a self-signed certificate will be automatically generated and saved to /data/ssl-keys/selfsigned.{key,cert}. See Let's Encrypt below for a CA-signed cert.

The web services will be available on port 3443 under /bwt/, /explorer/ and /specter/.

The unauthenticated Electrum SSL server will be available on port 50002. It should not be exposed directly to the Internet and is meant to be used behind an authentication layer like SSH or Tor.

When AUTH_TOKEN is set, NGINX will be configured to authenticate the password before forwarding traffic to the backend web services. This helps protect them against exploitation of security vulnerabilities.

Options

• SSL=0 (disabled by default, set to 1 to enable)
• AUTH_TOKEN=<none> (setup htpasswd-based login enforced by nginx)

Paths

• /data/ssl-keys/selfsigned.{key,cert} (keys and certificates)

Ports

• 3443 (HTTPS)
• 50002 (Electrum RPC)

📃 Let's Encrypt

To obtain a CA-signed certificate from Let's Encrypt, set SSL=1 SSL_DOMAIN=<domain> and publish the HTTP/S ports for remote access, like so:

docker run -it -p 443:3443 -p 80:8080 ... eznode/eznode SSL=1 SSL_DOMAIN=mynodebox.com

With existing webserver

server {
    listen 80;
    server_name ez.mynodebox.com;
    location /.well-known/acme-challenge/ { proxy_pass http://localhost:8080; }
}

Options

• SSL_DOMAIN=<none> (obtain CA-signed certificate for the given domain)
• LETSENCRYPT_EMAIL=<none> (for renewal and security notices, optional)
• LETSENCRYPT_LOGS=0 (display letsencrypt’s logs in the docker run output)

Paths

• /data/ssl-keys/letsencrypt (keys and certificates)

Ports

• 8080 (HTTP, for domain verification)