Page Comparison

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

...

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

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 When used as illustrated, 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.

...

• Connect to your CAS host via a different/working SSH, and append authorize 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

  • 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

...

.

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 request a “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 from the default.

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

...

...

Install autossh:

sudo apt update && sudo apt install autossh

...

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 (change if required)
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 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.

...

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

...

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

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 2>&1 | tee -a /root/autossh.log

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

autossh -v -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 2>&1 | tee -a /root/autossh.log

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