Skip to main content

New Install - Handle SSH Keys

If you followed the recommended setup instructions to build your VPS to run your node on, you should have gone through the process of creating ssh keys.

Unless you are running your node in a specialized way (advanced users) that require the use a username/password method of accessing your future node, we recommend the use of SSH keys.

Choose authentication method

We will choose the default option y (or just hit the enter key).

========================================
= SSH KEYS =
========================================
There are 2 main ways to connection to VPS or bare metal
servers.

1 SSH KEY passphrase/keyphrase
2 VPS admin user's password

IT IS HIGHLY RECOMMENDED YOU SETUP THIS VPS WITH SSH KEYS

If you followed the provided instructions and are not an advanced user, you most likely setup
your VPS with SSH key pairs.

Did you use an SSH key pair? [y]: y

nodectl will locate the SSH keys you are using and transfer it over to your new administrative (nodeadmin) user's account, to allow access; as well as, update necessary files.

Transferring SSH key to [nodeadmin] ........... completed

Disable common accounts

To add more security to our future node, we will now be offered the chance to disable remote access via the user accounts that we will no longer be using.

Also, we will disable the root user account's ability to remotely access our node. The root user should only be used sparingly for full access necessities. We will access the root user; as needed, via the nodeadmin account.

Once completed, we will only access our node from the nodadmin account. This is a good security measure.

note

The node in this tutorial is being created using an AWS instance in the cloud. AWS uses a commonly known ubuntu user for initial access.

nodectl attempts to be as smart as possible to identify default accounts from other cloud providers; such as:

  • Digital Ocean
  • Google Cloud Provider (GCP)
  • Heztner

Disable root

With the successful completion of our connection tests, we are assured we are able to access our node via our nodeadmin users. We can now safely allow nodectl to disable the root user's remote access.

We will only use the root user by connecting through nodeadmin and then switching to the root user as necessary via the sudo command.

Advanced Concerns

Do not worry if some of this information seems advanced. At the end of the day, you should not need to access the root user to run your node.

In the event you have any issues, you can access Constellation Network's Discord channel, to request help and advice.

We are confident you can simply follow the instructions to build your node as recommended.

We should say y at the prompt below.

nodectl will default to n for the protection of user, as this is an advanced security measure. We will not accept the default option.

We will enter say y (or hit enter key), for the next question involving special accounts.


The root user should not have access via SSH nor should AWS's default ubuntu user or other provider's admin users.

Access should be disabled so that only the node Administrator has access to this VPS with the nodeadmin user.

This is recommended.

Disable SSH access to these root and special accounts? [y]: y

nodectl will disable these accounts.

note

This is reversible if desired via the enable_root_ssh command.

nodectl will begin the process of disabling the special account's SSH access, and will ask for some confirmations.

Disabling [SSH] for root, ubuntu and/or admin.. disable

Password Authentication

In most situations, especially on cloud provider VPS systems where SSH access is the main way to access your VPS, you should disable password authentication. This will help prevent against brut force password attacks and other attack vectors.

Recommendation is to choose y here.

Recommended During the installation SSH was chosen.
Do you want to disable username/password based authentication on this node at the Operating System level to improve security?

Disable username/password access? [y]:

Next up access testing

In the next section, we will pause to verify some access tests before continuing the installation.