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 (supported) 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. The 2 servers can then chat with each other (back and forth) indefinitely while the SSH connection persists.

• 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.

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 intended 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.

Build a SSH keyset.

Create an ed25519 SSH key:

• 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.

• When used as illustrated, the public key will 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 & 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):

• Connect to your CAS host via a different/working SSH, and authorize the new public key.

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

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

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

Test the new key.

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

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

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

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

Install autossh:

Create a script to start the autossh tunnel:

Add the following content to the script:

• 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 port from the test already performed).

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

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

Make the script executable:

Test the script.

Manually run the script to ensure it works:

• 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, or the connection fails. It will retry silently in the background. 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:

Append the following line:

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

Troubleshooting

If autoSSH is failing to connect, you can troubleshoot it by 1) adding logging, and 2) increasing verbosity.

First, doublecheck that SSH is working as expected (above).

To log autoSSH output, modify the script line invoking autoSSH to:

• This will send logging to the file /root/autossh.log

If the log doesn’t provide enough info, you can try increasing it’s verbosity:

• increasing verbosity also increases the size of the log over time.