Page Comparison

...

Each daemon listens on a certain "port". The port is specific to each server and the daemon(s) it runs. The Internet address of the server ("host") and the port it listens on must be correctly specified in CAS for a successful data conversation.

The General Bytes CAS supports many different cryptocurrencies. Each one requires different parameters, and this is turn varies by the wallet provider you elect to use. This information may be known definitively to GB, and the wallet will be pre-populated with wallet providers (e.g. Coinbase, Kraken, etc). Other wallets are unknown to GB, but you have the option of using those wallets if you can acquire the required parameters from the wallet provider.

...

• 8332: Bitcoin Core

• 8332: Bitcoin Cash

• 8545: Ethereum

• 8333: Litecoin

• 18081: Monero

• 9998: DASH

• 11001: Sumcoin

• 8090: Cardano

User: this is the "user" portion of the RPC credentials given to you by the wallet operator. If you created your own node, then you set your own "user".  RPC credentials are entirely different than account credentials, and the two are rarely identical.

...

http:TheDutch:6szuvplZHgwKWrif_Ms2StzICOJLp4jbwsPRgPiKDqA=:127123.0123.0123.1123:8332:PITCO

• There are no quotes.

• All fields are seperated by a colon (":").

• Empty fields are skipped ("::"). NO SPACE BETWEEN THE COLONS!

...

...

Port Forwarding

You need 2 servers to share information? There’s many ways to do that, but the most private & secure method (so far) implements an SSH tunnel.

SSH is “Secure Shell”, and it’s basically an encrypted exchange of data between your computer & another. In the case of an SSH “tunnel”, you’re not involved. The computers talk to each other, with all the security & privacy guaranteed by SSH. This article covers some solid basics, but doesn’t pretend to teach network security. Get professional help if you value your money & the business that generates it.

Typically, once an SSH tunnel is established, it is left in service the entire time. It’s never turned off (though it can be) but needs to be started every time that one (or the other) computer is rebooted.

The GB Wallet Tunnel was created to simplify this process. It is encouraged, but not required. You can use either approach.

• See: Install the GB Wallet Tunnel Server

The SSH tunnel must be key-based. Yes, you can use a login password instead, but it’s so insecure that I won’t even discuss it. We’re using keys; end of discussion.

Terminology

Let’s agree on a few terms to avoid confusion below.

• You’re connecting a remote node server. We’ll call that the “node”.

• You’re “dialing out” from a local computer. We’ll call that the “local”.

• Lastly, you’ll be connecting a CAS server to the remote. We’ll call the CAS server: “CAS”.

Create a key pair.

The node will we “dialing out” to CAS, so we’ll create the key pair on the node.

1. Login to your node.

2. Create a type “ed25519” public key pair:

ssh-keygen -t ed25519

• Using a password is encouraged, but prohibits automation. If someone somehow gains root access to your node, they’ll have access to your CAS server - if you don’t use a password. When the node must be restarted (for any reason, e.g. after updates), the key must be unlocked each & every time. It adds complexity to the restart procedure, but adds an extra layer of security. Usually the node will only be restarted manually anyhow, so using a password is advised.

• When offered, enter a password to encrypt your key. The password shouldn’t be crazy-complex, but not too easy, either.

• Note the names of the public & private keys. The default save location is “$HOME/.ssh” - which is what we’ll assume was used, as well as the default key file names:

  • private key = “id_ed25519”, so it’s full path is normally: $HOME/.ssh/id_ed25519

  • public key = “id_ed25519.pub”, full path = $HOME/.ssh/id_ed25519.pub

  • save the public key contents locally. It’s not a sensitive item, and you can share it freely without worrying about somebody intercepting it. They can’t hack it. It’s safe.

  • the private key is the magic; protect it at all costs, and it’s a required tunnel parameter.

You’ll need to view the public key for the next step.

cat $HOME/.ssh/id_ed25519.pub

Authorize the key.

We need to authorize the public key. The public key is shared with systems that you want to access. They authorize your public key by adding it to a list.

Open another Terminal window & login to your CAS server.

Type:

wget -qO - ipv4.icanhazip.com

results in your CAS' public IP address. You’ll need that in the next step.

Now let’s authorize your public key:

1. Open the authorization list:

   Code Block
   mkdir $HOME/.ssh nano $HOME/.ssh/authorized_keys

2. Copy & Paste the public key file contents (press Ctrl-Shift-V to paste into nano).

3. Exit and save (Ctrl-X, then “Y”).

Typing this:

cat $HOME/.ssh/authorized_keys

should display something like this:

• Image Added

If no errors, then you’re good to move on to the next step. The key entered will only work for a login that has it listed in their file. Multiple users can add that public key. In this example, the user’s login name is “demo” (see the “demo@blackbox” prompt?).

Assemble the SSH parameters.

You started reading this article with the port in hand. Read the docs!

• In this example, we’ll forward port 8090.

The login username and CASIP address are determined by your CAS server credentials.

• in this example, we’ll use demo@123.123.123.123

The private key was created in the first step.

• in this example, we’ll use $HOME/.ssh/id_ed25519

Try the tunnel.

First, make sure you’ve set it up properly so far. Fill in the correct parameters here:

ssh -i $HOME/.ssh/id_ed25519 demo@123.123.123.123

This should result in an SSH login prompt on your CAS server.

• Your key password will be requested (assuming you created it that way).

• The CAS server fingerprint may be identified as “new”, if so - permit it to proceed (reply: yes).

Exit the connection (type “exit”) if no errors are shown.

• if you see errors, return to the beginning, check your syntax! Something’s wrong.

...

We’re ready to proceed if there were no errors so far.

Type this (with the correct parameters inserted) to create a tunnel to your CAS server:

ssh -f -N -i $HOME/.ssh/id_ed25519 -R 8090:127.0.0.1:8090 demo@123.123.123.123

• Enter the requested password again (if any).

• You’ll have to repeat this process anytime you reboot this node, or your CAS server.

Test it.

Your relevant CAS Crypto Setting tests should now pass, as though the node were running on your CAS server. NOTE: you must modify your CAS Crypto Setting parameter’s “host” when using an SSH tunnel.