SSH Tunneling

SSH tunneling, also known as SSH port forwarding, is a method of securely transmitting data between two networked devices. By leveraging the SSH (Secure Shell) protocol, SSH tunneling encrypts the data being transmitted, ensuring privacy and integrity. This technique is commonly used to bypass firewalls, secure network services, and access remote resources safely.

For most commercial applications, the GB Wallet Tunnel is simpler and safer to use.

• Do not use both types for the same node/server. Use one, or the other - never both.

• Instructions: https://generalbytes.atlassian.net/l/cp/JZtQfCfH

Key Concepts

SSH Protocol is a cryptographic network protocol designed for secure data communication, remote command-line login, and other secure network services between two networked computers. SSH is encrypted and extremely secure when properly deployed.

Local Port Forwarding is a technique where a local port on your machine is forwarded to a specific port on a remote server through an SSH connection. This means that any traffic sent to the local port is securely tunneled through the SSH connection to the designated port on the remote server.

• In this example, the local server will be a Bitcoin node, and

  • the port will be the Bitcoin node RPC port (8332).

• The remote server (in this example) is your CAS host.

• We will share the same port (8332) from the local server to the remote server.

The local server “dials out”. The conversation is bidirectional, but the connection is initiated by the local server (the Bitcoin node), e.g. the Bitcoin node connects to the remote CAS, and then the 2 servers can chat with each other (back and forth) indefinitely.

• The connection must always be active/alive/awake.

• If the connection fails for any reason, CAS will not be able to communicate with the server until the connection is reestablished.

This article will only employ Local Port Forwarding, and all instructions are confined to that mode. Other modes (remote, proxy) exist, but will not be described as they are irrelevant to the goal.

Overview

These instructions will:

1. Build a SSH keyset.

2. Install autossh to maintain a persistent, fault-tolerant connection between the 2 servers, and

3. script the process to automatically start during boot.

Create an Ed25519 SSH Key

sudo ssh-keygen -t ed25519 -C "bitcoin@cas" -f /root/.ssh/cas_tunnel.ed25519

• Creates the keyset on the local server with root ownership and permissions.

• Root ownership avoids signal and permissions issues.

• Change the comment "bitcoin@cas" to whatever you feel is relevant (using legal characters).

• Do not set a password/passphrase for the key. Using autossh negates that security.

• The public key will now normally be saved as: /root/.ssh/cas_tunnel.ed25519.pub

• Print the key's randomart image and hang it on the wall to show off to your friends and family.

Connect to your CAS server via SSH and authorize the new public key.

This command displays the public key required to be authorized on your CAS server (the remote):

cat /root/.ssh/cas_tunnel.ed25519.pub

• Connect to your CAS host via a different/working SSH, and append the new public key to your root’s authorized_keys file.

• On the CAS server, you’ll normally use sudo nano /root/.ssh/authorized_keys to open the file.

  • Once successfully pasted/appended to the file, save and exit nano on the CAS server.

  • Be careful not to erase any previous keys already in the file!

Test the new key!

sudo ssh -i /root/.ssh/cas_tunnel.ed25519 -p 22 root@CAS_SSH_IP

• This should confirm that a new host has been found, and press “Y” to add it to the known_hosts file.

• Do not proceed until SSH successfully connects using the new key.

• REQUIRED: replace CAS_SSH_IP with your CAS server’s actual public IP address.

• Change the port (22) if yours is something different.

• 99% of your future tunneling problems can be identified using this simple test.

• The connection must be established with no typing required (for autossh) - so if you must type ANYTHING using this test - then autossh will fail (it can’t type “y” or anything else for you).

Install autossh:

sudo apt update && sudo apt install autossh

Create a script to start the autossh tunnel:

sudo nano /usr/local/bin/cas_tunnel.sh

Add the following content to the script:

#!/bin/bash 
AUTOSSH_POLL=60 # do not modify this line
AUTOSSH_PORT=0 # do not modify this line
FORWARDED_PORT=8332 # example for Bitcoin Core
CAS_SSH_IP="123.321.123.321" # MUST BE CHANGED to the proper CAS IP
CAS_SSH_PORT=22 # this is the default CAS SSH port number
IDENTITY_FILE=/root/.ssh/cas_tunnel.ed25519 # SSH private key file

autossh -M 0 -f -N -i $IDENTITY_FILE -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -R $FORWARDED_PORT:127.0.0.1:$FORWARDED_PORT -p $CAS_SSH_PORT root@$CAS_SSH_IP

• REQUIRED: set the CAS_SSH_IP to your actual CAS server public IP address (remote IP).

• Change the CAS_SSH_PORT remote port if necessary (same as from the test already performed).

• Change the FORWARDED_PORT to whatever port it is you’re forwarding (example is Bitcoin Core).

• The IDENTITY_FILE should not be changed if you followed the previous directions.

Make the script executable:

sudo chmod +x /usr/local/bin/cas_tunnel.sh

Test the script.

Manually run the script to ensure it works:

sudo ./cas_tunnel.sh

• You should see no errors if everything was entered correctly.

• Test CAS (e.g. Crypto Settings) to ensure it can also communicate with the local server.

• You can also use curl tests on the CAS console for troubleshooting (point it to IP 127.0.0.1).

• Autossh will not complain if a setting is wrong. If the forwarding is failing, check your settings using plain SSH (as described above).

Set the script to run at boot/startup.

If everything works as expected, add the script to crontab for execution at reboot:

sudo crontab -e

Append the following line:

@reboot /usr/local/bin/cas_tunnel.sh

• To disable the script in crontab, simply add a hashtag '#' to the very beginning (the first character).