Venturing into the digital world and engaging in a crypto project can be thrilling, but following top security practices is essential. Here is a general guide to security and safety, including basic measures for securing servers and home PCs. Your adherence to these practices contributes to the stability of the Subspace network and, of course, the safety of the community's cryptoassets.
Enjoy Subspace journey with peace of mind!
Be sure to make the password long enough, combining both registers letters, numbers, and special characters. An 11-character password increases the bruteforce attack time to normally impossible limit. Take a look at passwords brutforce time illustrating table. However, even a complex password is not all, that is required for proper protection.
Avoid using common or easily guessed combinations of words or letters, as well as parts of your online data or reusing any of your existing passwords.
Weak password example:
Strong password example:
Consider using a password manager to generate complex passwords and store them securely. There are plenty of password managers available. Ensure that the password manager of your choice stores data in encrypted form, boasts a robust password generator, receives positive reviews, and has a history of consistent updates. For example, well-regarded options include KeePass, Bitwarden, 1Password, LastPass, Dashlane, and Keeper. However, it's crucial to do your own research and consult ratings before making a decision.
Boost the security of your accounts by enabling 2FA (two-factor authentication) wherever possible. This extra layer of protection requires a second verification step, such as a code from a mobile app or hardware token, in addition to your passwords.
Do not share your 12-word seed phrase or private keys.
A hardware wallet is by far the most secure way to store your private keys. Unlike online exchanges and wallets, hardware wallets store the keys offline and protect from potential malware or hacking attempts. The most popular hardware wallets are Ledger and Tresor.
Back up your wallets by securely storing the backups offline or in an encrypted cloud storage. This guarantees that you can recover your funds in case of a device loss, damage, or theft. Many encrypted cloud storage services are available, such as Tresorit, pCloud, Sync.com, SpiderOak, and Mega (the order doesn't matter). However, always conduct your own research.
Keep all software up to date.
Be cautious of public Wi-Fi.
Subspace team members will never initiate direct messages with you.
Should you receive an unsolicited message, it's best to ignore it, block the sender, and promptly report the incident to our "scam report" channel.
Exercise caution with regard to phishing attacks. Do not click on links within our forum, Discord, or Telegram, unless those links have been shared by a trusted member of our team, such as ambassadors or staff. Scammers can create deceptive links that mimic legitimate websites, so it's advisable to scrutinize the message's author (on all the mentioned platforms) before clicking any links. Trust should generally be reserved for project team members, ambassadors, or highly reputable farmers.
SSH RSA Keys-based Secure Authentication
Let's run through some basics.
SSH is a network protocol used for secure remote access to computer systems, cloud infrastructure, secure file transfer (SFTP), and tunneling. It's a fundamental tool for system administrators and developers. SSH uses the Diffie-Hellman algorithm for secure connections and authentication methods like password or SSH key pairs.
SSH Connection Establishment.
When a client initiates a TCP connection, the server responds with supported protocol versions and its public host key. Both parties negotiate a session key using the Diffie-Hellman algorithm to ensure secure communication. This session key encrypts the entire session.
After establishing session encryption, user authentication begins. Password authentication involves securely transmitting the user's account password. SSH key pairs, consisting of public and private keys, are a recommended alternative for authentication. The client sends a key pair ID to the server, which checks for a matching public key. The server encrypts a random number with the public key, sent to the client, who decrypts it with the private key. The client computes an MD5 hash using the decrypted number and the shared session key, sending it back to the server for verification.
In RSA, encryption and decryption use different keys: the encryption key is public, and the decryption key is private. A user creates a public key based on two large prime numbers and an auxiliary value, while keeping the prime numbers secret. Messages can be encrypted with the public key but can only be decrypted by someone who knows the prime numbers.
Together, SSH and RSA provide secure, authenticated, and encrypted connections to protect sensitive information. To enhance security, though it is possible to create an SSH key with a passphrase.
Creating RSA Key Pair
To allow PublicKey authentication on your server, as root run:
PubkeyAuthentication no --> PubkeyAuthentication yes
systemctl restart ssh
Create RSA keys on a Home PC:
you will get two keys:
$HOME/.ssh/id_rsa Your private RSA key to keep on local PC
$HOME/.ssh/id_rsa.pub Your public RSA key to send to a server
Transfer RSA Keys to a Server:
sudo ssh-copy-id -p 12345 user_name@server-ip-addres
This utility specifically designed for copying SSH keys to a remote server.
It automatically handles the key placement and permissions on the remote server, making it more convenient.
-p flag to specify not standard port, if you have changed it.
If you have created keys before, don't overwrite it! As you will not be able to authenticate using the previous key anymore. But you can keep them somewhere else and generate them next.
Alternative Ways to Transfer RSA Public key to a Remote Server:
If you have created keys before and store them elsewhere, you can use rsync to copy the contents of the public key from any other place to
authorized_keys by specifying the path to the keys:
sudo rsync -e "ssh -p 12345" ~/.ssh/user2/id_rsa.pub USER@SERVER_IP:~/.ssh/authorized_keys
-p flag for specifying not standatr port
This command will create an .ssh dir on a server(or skip if it has) and add the keys to the end of
cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
-p flag make the tool to skip the error if the directory already exists
Manually transfer the public key file and add it to the
authorized_keys file on the remote server.
You can open
id_rsa.pub key and copy-paste it's content to the end of
echo public_key_string >> ~/.ssh/authorized_keys
Make sure you have permissions 700 for
~/.ssh directory and 600 for
authorized_keys in it
Testing the Secure Connection
Streamlining SSH Connections Management With Aliases
Managing connections can be much simplier and more enjoyable by creating aliases!
Create a file named "config" in the
~/.ssh directory (where the keys are), simply add your server or other users for the same server to it, like in example below. Feel free to add as many as you want.
Host Farm # Any word can be used here as an alias (for ex. "subspace" or "Farm")
HostName 22.214.171.124 # Use you server's IP
Port 12345 # your custom port
User username # User for login (for a rescue system this must be root, change it later)
indentation isn't important, 4 spaces indentation is used for a better readability
Try to connect using simpliest syntax in terminal:
You will be asked if you allow the connection. Reply with 'yes'.
Alternating SSH Port
By default, SSH (Secure Shell) listens on port 22. This is well-known and can be a target for automated attacks. By changing the SSH port, you make it harder for attackers to guess which port SSH is listening on, reducing the risk of automated attacks.
First, make sure you don't have UFW enabled. If you do, add a rule for the desired port:
sudo ufw allow 12345/tcp #this is an example, specify your port
- Changing port
sudo vi /etc/ssh/sshd_config
#Port 22 -> Port 12345 # specify a custom SSH port within the range of 1025 to 65534
sudo systemctl reload sshd # for the changes to take effect
Checking new port from homePC
ssh -p 12345 user@localhost # specify your port
Now you can log in to your server on a non-standard port using an encrypted connection without entering any credentials!
Basic Recommendations for Configuring the SShd Configuration File
As root, edit sshd_config:
Allowing Public Key authentication:\
PubkeyAuthentication no --> PubkeyAuthentication yes
Restricting password access:\
PasswordAuthentication yes --> PasswordAuthentication no
Reducing time window for entering credentials:\ (If the authentication process is not completed within this time, the server will terminate the connection)\
Restricting root login\
PermitRootLogin yes --> PermitRootLogin no
Specifying the Users allowed to connect through SSH\
AllowUsers user1 user2
Reload daemon for the changes to take effect:
systemctl reload sshd
- Reboot your system to ensure that everything is functioning as expected.
Complete SSh manual: SSH Academy
A Word About Partitioning as a Security Measure.
As a security measure, it is worth mentioning the practice of allocating separate partitions for critical directories such as /boot, /var, /tmp, and /home (in some cases). This helps isolate system files, logs, temporary files, and user data, which can improve system stability and security. But the cons are there too:
- If one partition runs out of space while another partition has unused space, it may not be possible to easily reallocate the disk space
- Monitoring and maintaining each partition separately, including backups, permissions
- having a separate /tmp partition may result in increased disk I/O when temporary files are created and deleted
- If the /home partition is separate, migrating to a new server or upgrading the operating system may require additional steps to ensure the proper migration of user data and configurations
- Having separate partitions can increase the risk of data loss if one partition fails or becomes corrupted
The partitioning recommendations for farming in Subspace will be covered in the "Partitioning and mounting file system" section of the left tab menu.
While Linux distributions regularly release security patches to address known vulnerabilities in software packages, it doesn't always make sense to install every available update on a server. Unnecessary updates can introduce features or changes that might not be needed and, in some cases, may even cause system destabilization. If you've made customizations or modifications to your server's configuration or software, an upgrade could potentially overwrite or conflict with these changes.
Therefore, it's essential to make upgrade decisions based on a thorough understanding of what each package does and reviewing their changelogs.
To view the changelog for a particular package:
apt changelog <package_name>
While kernel updates often come with bug fixes and security patches, there is a possibility that the new kernel version may introduce new bugs or compatibility issues. Not every kernel update is necessary or urgent. Some updates may provide incremental improvements or additional functionality that may not be essential for your specific use case. It's important to evaluate the benefits and potential risks before deciding to update the kernel.
Upgrading the distribution version
- Access to new features
- Software compatibility
- Security updates
- Long-term support (LTS)
- Potential for compatibility issues
- Configuration changes
- May have new bugs (which can be resolved by downgrading the bugged package).
So everywhere ideally it is necessary to read changelogs, know what is needed and why, and comprehensively evaluate the need for upgrades. Although, of course, in most cases under ordinary (office) conditions everything should work.
To Access Release Notes:
Simply use the search function on the Ubuntu homepage.
According to the ordering of UFW rules (DENY rules should come first, followed by ALLOW rules), new 'ALLOW' rules can simply be added to the end of the existing rules.
your existing rules
sudo ufw allow 30333 comment 'Node port'
sudo ufw allow 30433 comment 'Node DSN port'
sudo ufw allow 30533 comment 'Farmer port'
Now with peace of mind you may go back to installing Node and Farmer.